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Foreword 


(This  Foreword  is  not  part  of  American  National  Standard  X3. 133-1986.) 

American  National  Standard  Database  Language  NDL  specifies  the  syntax  and  semantics  of  interfaces  to  a 
database  management  system  for  defining  and  accessing  network  structured  databases.  Together,  these  inter¬ 
faces  are  called  Database  Language  NDL. 

This  standard  was  developed  by  the  Technical  Committee  on  Database,  X3H2,  under  two  projects  authorized 
by  the  Accredited  Standards  Committee  on  Information  Processing  Systems,  X3.  Project  309D,  described  in 
document  ANSI  X3/SPARC/77-34,  called  for  the  development  of 

"...an  American  National  Standard  for  a  Data  Description  Language  to  be  used  in  designing,  main¬ 
taining,  controlling,  and  protecting  databases,  based  on  the  specifications  set  forth  in  the  Journal  of 
Development  (JOD)  published  by  the  Data  Description  Language  Committee  (DDLC)  of  the  Confer¬ 
ence  on  Data  Systems  Languages  (CODASYL)." 

Under  project  309D,  Technical  Committee  X3H2  was  specifically  not  chartered  to  develop  standard  interfaces 
for  accessing  databases.  The  X3  Technical  Committees  on  COBOL  and  FORTRAN  were  responsible  for 
specifying  the  syntax  and  semantics  of  the  language  facilities  (subschema  data  definition  and  data  manipu¬ 
lation)  necessary  to  access  databases  defined  using  Technical  Committee  X3H2’s  standardized  data  definition 
language. 

A  1981  Technical  Committee  letter  ballot  on  a  Data  Definition  Language  for  Network  Structured  Databases 
indicated  that  Technical  Committee  X3H2  members  were  unwilling  to  forward  the  document  to  X3  for  proc¬ 
essing  as  a  standard  without  specifications  of  language  for  accessing  databases.  Committee  X3  then  approved 
project  355D,  which  is  described  in  document  ANSI  X3/SP ARC/8 1-191  as  follows: 

"To  develop  a  comprehensive  standard  for  a  data  definition  language  and  for  database  control  system 
functions  to  be  used  in  designing,  accessing,  maintaining,  controlling,  and  protecting  databases." 

The  new  project  355D  subsumed  the  activities  carried  out  under  the  data  description  language  project  309D, 
adding  responsibility  for  defining  the  semantics  of  database  access  facilities.  Standards  development  commit¬ 
tees  for  programming  languages  retained  the  responsibility  for  specifying  programming  language  specific  syntax 
for  invoking  the  database  access  facilities  defined  by  Technical  Committee  X3H2. 

American  National  Standard  Database  Language  NDL  is  the  culmination  of  work  by  many  groups.  Under 
project  309D,  the  January  1978  Journal  of  Development  of  the  CODASYL  Data  Description  Language  Com¬ 
mittee  provided  the  basis  for  the  NDL  data  definition  language  syntax  and  semantics.  When  project  355D 
called  for  development  of  standard  database  access  facilities,  Technical  Committee  X3H2  added  to  its  base 
document  a  specification  of  subschema  and  data  manipulation  facilities  adapted  from  the  July  1980  Revision 
Working  Paper  of  the  Technical  Committee  on  COBOL,  X3J4,  Section  XVI:  "Database  Module".  That 
working  document  of  X3J4  had  been  adapted  from  the  Database  Module  of  the  January  1978  Journal  of 
Development  of  the  CODASYL  COBOL  Committee,  derived  from  the  earlier  specifications  of  the  CODASYL 
Database  Task  Group  (DBTG).  During  work  on  the  NDL  standard,  Technical  Committee  X3H2  addressed  all 
proposals  that  were  submitted,  whether  for  addition,  deletion,  or  change. 

This  standard  was  approved  as  an  American  National  Standard  by  the  American  National  Standards  Institute 
on  August  1,  1986. 

Suggestions  for  improvement  of  this  standard  are  welcome.  They  should  be  sent  to  the  Computer  and  Business 
Equipment  Manufacturing  Association,  311  First  Street  NW,  Washington,  DC  20011. 


This  standard  was  processed  and  approved  for  submittal  to  ANSI  by  the  Accredited  Standards  Committee  on 
Information  Processing  Systems,  X3.  Committee  approval  of  this  standard  does  not  necessarily  imply  that  all 
committee  members  voted  for  its  approval.  At  the  time  that  it  approved  this  standard,  the  X3  Committee  had 
the  following  members: 
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American  National  Standard 
for  Information  Systems  - 


Database  Language  - 
NDL 


1.  Scope  and  field  of  application 


This  standard  specifies  the  syntax  and  semantics  of  three  database  languages: 

1)  A  schema  definition  language,  for  declaring  the  structures  and  integrity  constraints  of  an  NDL  database. 

2)  A  subschema  definition  language,  for  declaring  a  user  view  of  that  database. 

3)  A  module  language  and  data  manipulation  language,  for  declaring  the  database  procedures  and  executable 
statements  of  a  specific  database  application  program. 

This  standard  defines  the  logical  data  structures  and  basic  operations  for  an  NDL  database.  It  provides  func¬ 
tional  capabilities  for  designing,  accessing,  maintaining,  controlling,  and  protecting  the  database. 

This  standard  provides  a  vehicle  for  portability  of  database  definitions  and  application  programs  between  con¬ 
forming  implementations. 

This  standard  specifies  two  levels.  Level  2  is  the  complete  NDL  database  language.  Level  1  is  the  subset  of 
Level  2  defined  in  clause  13,  “Levels”  on  page  119. 

This  standard  does  not  specify  some  of  the  facilities  that  might  be  provided  in  operational  database  environ¬ 
ments,  such  as  the  following: 

1)  An  access  control  facility  for  granting  access  and  operational  privileges  to  specific  users 

2)  Additional  integrity  control  capabilities  for  specifying  more  complex  integrity  constraints  on  the  database 

3)  A  facility  to  import  and  export  schema  definitions 

4)  A  database  unload  facility  for  copying  record  and  set  populations  to  standard  files  for  information  inter¬ 
change 

5)  A  schema  database  for  making  schema  and  subschema  information  available  to  accessing  application  pro¬ 
grams 

6)  A  schema  manipulation  language  for  creating,  modifying,  or  deleting  portions  of  the  schema  or  subschemas 

7)  Interfaces  to  a  data  dictionary 

8)  Application  program  pre-processing  facilities  for  producing  separate  standard  database  modules  and 
standard  language  programs 
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9)  A  data  storage  definition  language  for  defining  physical  storage  structures  and  physical  access  methods 

10)  Database  procedures  for  user  specified  assertions  and  triggers 

1 1 )  A  natural  language  query  facility  for  ad  hoc  access  to  the  database 

12)  Report  generator  f acilities  for  producing  output  tables  and  charts 

13)  Graphics  capabilities  for  direct  database  interface  with  standard  graphics  systems 

14)  A  distributed  database  facility  for  defining  and  accessing  data  at  different  nodes  in  a  communications 
network 

Standards  for  such  additional  facilities  could  be  specified  in  a  manner  that  is  upward  compatible  with  this 
standard.  Some  of  the  additional  capabilities  might  be  specified  by  subsequent  versions  of  this  standard,  others 
could  be  specified  by  separate  standards,  and  some  may  always  be  implementor-defined. 

This  standard  applies  to  implementations  that  exist  in  an  environment  that  may  include  application  program¬ 
ming  languages,  end-user  query  languages,  report  generator  systems,  data  dictionary  systems,  program  library 
systems,  and  distributed  communication  systems,  as  well  as  various  tools  for  database  design,  data  adminis¬ 
tration,  and  performance  optimization. 
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2.  References 

2.1  American  National  Standards 

This  standard  is  intended  for  use  with  the  following  American  National  Standards.  When  these  standards  are 
superceded  by  revisions  approved  by  the  American  National  Standards  Institute,  the  revisions  shall  apply. 

ANSI  X3.9-1978,  ISO  1539-1980,  Programming  Language  -  FORTRAN. 

ANSI  X3. 23-1985,  ISO  1989-1985,  Programming  Language  -  COBOL. 

ANSI  X3. 53-1976,  ISO  6160-1979,  Programming  Language  -  PL/I. 


2.2  Other  Standards 

This  standard  is  also  intended  for  use  with  Programming  Language  -  Pascal  1,  BSI  BS  6192-1982,  ISO 
7185-1983. 


l 


This  British  Standard  is  available  from  the  American  National  Standards  Institute,  1430  Broadway,  New  York,  N.Y. 
10018. 
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3.  Overview 

3.1  Organization 

The  organization  of  this  standard  is  as  follows: 

1)  3.2,  “Notation”  on  page  5  and  3.3,  “Conventions”  on  page  6  define  the  notations  and  conventions  used 
in  this  standard. 

2)  3.4,  “Conformance”  on  page  7  defines  conformance  criteria. 

3)  Clause  4,  “Concepts”  on  page  9  defines  terms  and  presents  concepts  used  in  the  definition  of  NDL. 

4)  Clause  5,  “Common  elements”  on  page  17  defines  language  elements  that  occur  in  several  parts  of  NDL 
language. 

5)  Clause  6,  “Schema  definition  language”  on  page  31  defines  the  NDL  facilities  for  specifying  a  database. 

6)  Clause  7,  “Subschema  definition  language”  on  page  59  defines  the  NDL  facilities  for  specifying  portions 
of  a  database  that  can  be  referenced  by  an  application  program. 

7)  Clause  8,  “Module  language”  on  page  65  defines  NDL  modules  and  procedures. 

8)  Clause  9,  “Data  manipulation  language”  on  page  75  defines  the  data  manipulation  statements  of  NDL. 

9)  Clause  10,  “Auxiliary  operations”  on  page  107  defines  certain  operations  that  are  used  in  the  definition 
of  NDL  data  manipulation  statements. 

10)  Clause  11,  “Interpretive  state”  on  page  111  defines  the  "session  state",  which  is  used  in  the  definition  of 
NDL  data  manipulation  statements. 

11)  Clause  12,  “Status  codes”  on  page  117  defines  the  values  of  the  STATUS  parameter  after  the  execution 
of  NDL  data  manipulation  statements. 

12)  Clause  13,  “Levels”  on  page  119  defines  the  two  levels  of  NDL. 

3.2  Notation 

The  syntactic  notation  used  in  this  standard  is  BNF  ("Backus  Normal  Form"  or  "Backus-Naur  Form"),  with 

the  following  extensions: 

1)  Square  brackets  ([])  indicate  optional  elements. 

2)  Ellipses  (...)  indicate  elements  that  may  be  repeated  one  or  more  times. 

3)  Braces  ({})  group  sequences  of  elements. 
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In  the  BNF  syntax,  a  production  symbol  <A>  is  defined  to  "contain"  a  production  symbol  <B>  if  <B> 
occurs  someplace  in  the  expansion  of  <A>.  If  <A>  contains  <B>,  then  <B>  is  "contained  in"  <A>.  If 
<A>  contains  <B>,  then  <A>  is  the  "containing"  <A>  production  symbol  for  <B>. 

A  production  symbol  <A>  "immediately  contains"  a  production  symbol  <B>  if  <A>  contains  <B>  and  if 
<B>  occurs  in  the  first  expansion  of  <A>. 

The  lexical  units  of  this  standard  (e.g.  <separator>,  <key  word>,  <identifier>,  and  <literal>)  are  defined 
elsewhere  in  this  standard.  The  following  characters  have  special  significance  in  some  production  rules: 

In  <  escape  identifier > 

In  <  character  string  literal  > 

(  In  <comment>,  <condition>,  and  <subscripts> 

)  In  <  comment  >,  <  condition  >,  and  <  subscripts  > 

*  In  <  comment  > 

In  <  numeric  literal  > 

In  <  numeric  literal  > 

<  In  <  relation  > 

>  In  <  relation  > 

=  In  <  component  identifier  match  >,  <relation>,  and 
<test  database  key  equal  statement > 

E  In  < approximate  numeric  literal> 

In  <identifier> 

In  <component  identifiers  <component  view  identi¬ 
fier  >,  <  numeric  literal  >,  <  subschema  name  clause  >, 
and  <  subschema  specification  > 

3.3  Conventions 

Syntactic  elements  of  this  standard  are  specified  in  terms  of: 

1)  Function :  A  short  statement  of  the  purpose  of  the  element. 

2)  Format :  A  BNF  definition  of  the  syntax  of  the  element. 

3)  Syntax  Rules :  Additional  syntactic  constraints  not  expressed  in  BNF  that  the  element  shall  satisfy. 

4)  General  Rules :  A  sequential  specification  of  the  run-time  effect  of  the  element. 

In  the  Syntax  Rules,  the  term  "shall"  defines  conditions  that  are  required  to  be  true  of  syntactically  conforming 
NDL  language.  The  treatment  of  NDL  language  that  does  not  conform  to  the  Formats  or  the  Syntax  Rules  is 
implementor-defined. 

A  conforming  implementation  is  not  required  to  perform  the  exact  sequence  of  actions  defined  in  the  General 
Rules,  but  shall  achieve  the  same  effect  on  the  database  as  that  sequence. 

The  term  "persistent  object"  is  used  to  characterize  objects  such  as  <module>s  and  <schema>s  that  are 
created  and  destroyed  by  implementor-defined  mechanisms. 

In  this  standard,  clauses  begin  a  new  odd-numbered  page,  and  in  clause  5,  “Common  elements”  on  page  17 
through  clause  11,  “Interpretive  state”  on  page  111  subclauses  begin  a  new  page.  The  resulting  blank  space  is 
not  significant. 
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3.4  Conformance 

This  standard  specifies  conforming  NDL  language  and  conforming  NDL  implementations.  Conforming  NDL 
language  shall  abide  by  the  BNF  Format  and  associated  Syntax  Rules.  A  conforming  NDL  implementation 
shall  process  standard  conforming  NDL  language  according  to  the  General  Rules. 

A  conforming  implementation  may  provide  additional  facilities  or  options  not  specified  by  this  standard.  An 
implementation  remains  conforming  even  if  it  provides  user  options  to  process  nonconforming  NDL  language 
or  to  process  conforming  NDL  language  in  a  nonconforming  manner. 

This  standard  does  not  define  the  method  or  the  time  of  binding  between  application  programs  and  database 
management  system  components. 

An  implementation  that  conforms  to  Level  1  of  this  standard  shall  meet  the  requirements  for  Level  2  conform¬ 
ance  except  that  it  may  omit  certain  facilities  as  specified  in  clause  13,  “Levels”  on  page  119. 

This  standard  specifies  three  languages  and  defines  the  syntax  and  semantics  of  each  of  them.  Implementors  of 
database  management  systems  may  claim  conformance  for  their  products  to  this  standard  in  two  ways.  An 
implementation  may  support  the  identical  syntax  of  the  languages  and  claim  both  syntactic  and  functional  con¬ 
formance,  or  it  may  use  different  syntax  to  express  the  same  concepts,  semantics,  and  functionality,  and  claim 
functional  conformance  only. 

Implementations  claiming  functional  conformance  to  any  of  the  three  standard  languages  shall  specify  equiv¬ 
alence  with  the  semantics  and  functionality  of  those  standard  languages.  For  example,  it  should  be  possible  to 
show  that  a  schema  displayed  by  a  database  management  system  display  utility  could  be  recoded  using  the 
standard  schema  definition  language  syntax  and  have  equivalent  functionality. 
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4.  Concepts 


4.1  Data  type 

A  <data  type>  is  a  set  of  representable  values.  The  logical  representation  of  a  value  is  a  <literal>.  The 
physical  representation  of  a  value  is  implementor-defined. 

A  value  is  primitive,  in  that  it  has  no  logical  subdivision  within  this  standard.  Values  are  the  basis  of  definition 
for  data  items  and  arrays. 

A  value  is  either  a  character  string  or  a  number.  A  character  string  and  a  number  are  not  comparable  values. 

4.1.1  Character  strings 

A  character  string  consists  of  a  sequence  of  characters  of  the  implementor-defined  character  set.  A  character 
string  has  a  length,  which  is  a  positive  integer  that  specifies  the  number  of  characters  in  the  sequence. 

4.1.2  Numbers 

A  number  is  either  an  exact  numeric  value  or  an  approximate  numeric  value.  All  numbers  are  comparable 
values. 

An  exact  numeric  value  has  a  precision  and  a  scale.  The  precision  is  a  positive  integer  that  determines  the 
number  of  significant  decimal  digits.  The  scale  is  a  signed  integer.  A  scale  of  0  indicates  that  the  number  is  an 
integer.  For  a  scale  of  N,  the  exact  numeric  value  is  the  integer  value  of  the  significant  digits  multiplied  by  10 
to  the  power  -N. 

An  approximate  numeric  value  consists  of  a  mantissa  and  an  exponent.  The  mantissa  is  a  signed  numeric  value, 
and  the  exponent  is  a  signed  integer  that  specifies  the  magnitude  of  the  mantissa.  An  approximate  numeric 
value  has  a  precision.  The  precision  is  a  positive  integer  that  specifies  the  number  of  significant  binary  digits  in 
the  mantissa. 

Whenever  an  exact  numeric  value  is  assigned  to  a  data  item  or  parameter  representing  an  exact  numeric  value, 
its  value  shall  be  exactly  representable  in  the  data  type  of  the  target.  The  value  is  converted  to  have  the  preci¬ 
sion  and  scale  of  the  target. 

Whenever  an  exact  or  approximate  numeric  value  is  assigned  to  a  data  item  or  parameter  representing  an 
approximate  numeric  value,  an  approximation  of  its  value  is  represented  in  the  data  type  of  the  target.  The 
value  is  converted  to  have  the  precision  of  the  target. 
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4.2  Components 

A  component  is  either  a  data  item  or  an  array  of  data  items.  A  <component  type>  defines  a  collection  of 
component  occurrences  all  having  the  same  <data  type>. 

A  data  item  consists  of  a  single  value.  An  array  consists  of  a  sequence  of  data  items. 

An  array  is  specified  by  <extents>,  which  are  a  list  of  <  unsigned  integers  >.  The  number  of  data  items  that 
occur  in  an  array  is  equal  to  the  product  of  the  <unsigned  integer >s. 

A  data  item  not  contained  in  an  array  is  referenced  by  a  <component  name>  and  a  <database  key>.  A  data 
item  contained  in  an  array  is  referenced  by  a  Ccomponent  name>,  a  <database  key>,  and  <subscripts>. 

All  values  of  the  same  <component  type>  have  the  same  <data  type>.  If  the  Ccomponent  type>  defines  an 
array,  then  each  component  occurrence  is  an  array  with  the  same  dimension  and  extent  integers.  All  character 
strings  of  the  same  character  string  component  have  the  same  <  length  >.  All  numbers  of  the  same  exact 
numeric  component  have  the  same  <precision>  and  <  scale  >.  All  numbers  of  the  same  approximate  numeric 
component  have  the  same  <  precision  >. 

Every  Ccomponent  type>  is  defined  as  part  of  a  Crecord  type>.  The  Ccomponent  type>  specifies  the  cdata 
type>.  If  a  Ccomponent  type>  defines  an  array,  then  it  specifies  the  Cextents>.  A  character  string  Ccompo¬ 
nent  type>  specifies  the  Clength>  of  its  character  strings.  An  exact  numeric  Ccomponent  type>  specifies  the 
C precision >  and  C scale >  of  its  numbers.  An  approximate  numeric  Ccomponent  type>  specifies  the  C preci¬ 
sion  >  of  its  numbers. 


4.3  Records 

The  record  is  the  basic  unit  of  manipulation  in  this  standard.  Records  are  stored,  erased,  found,  modified,  and 
connected,  disconnected,  and  reconnected  in  sets. 

A  record  is  a  collection  of  components.  A  Crecord  type>  defines  a  collection  of  record  occurrences  all  having 
the  same  Ccomponent  type>s.  A  Crecord  type>  defines  its  Ccomponent  type>s,  and  specifies  integrity  con¬ 
straints  that  its  record  occurrences  shall  satisfy. 

Each  record  is  an  occurrence  of  exactly  one  Crecord  type>,  and  consists  of  exactly  the  components  defined  by 
that  Crecord  type>. 

The  records  of  each  Crecord  type>  are  maintained  in  an  implementor-defined  order. 


4.3.1  Database  keys 

All  records  are  distinguishable.  Each  record  is  identified  uniquely  by  a  C database  key>.  A  C database  key>  is 
either  null,  in  which  case  it  identifies  no  record,  or  it  is  nonnull  and  identifies  exactly  one  record  in  the  data¬ 
base.  A  Cdatabase  key>  has  no  logical  representation,  and  is  not  available  through  any  interface  defined  by 
this  standard.  The  physical  representation  of  a  Cdatabase  key>  is  implementor-defined. 

The  Cdatabase  key>s  are  used  to  model  cursors  in  the  session  state  and  to  define  the  semantics  of  statements 
in  the  data  manipulation  language.  In  the  session  state,  a  Cdatabase  key>  is  referenced  by  cdatabase  key>. 
In  data  manipulation  language  statements,  a  cdatabase  key>  is  referenced  by  a  Cdatabase  key  identifiers 
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4.3.2  System  record 

This  standard  assumes  the  existence  of  a  special  SYSTEM  Crecord  type>.  The  SYSTEM  <record  type>  has 
no  <component  type>s,  no  integrity  constraints,  and  exactly  one  imaginary  record  occurrence,  called  the 
system  record. 

This  standard  does  not  specify  a  <database  key>  for  the  system  record.  The  system  record  and  SYSTEM 
<record  type>  exist  only  for  the  definition  of  singular  sets. 


4.4  Set  types 

A  <set  type>  is  a  defined  relationship  between  two  or  more  <record  type>s. 

In  a  <set  type>,  one  Crecord  type>  is  designated  as  the  owner  Crecord  type>,  and  each  of  the  other  Crecord 
type>s  is  referred  to  as  a  member  Crecord  type>  of  the  Cset  type>. 

For  each  Cset  type>,  there  may  be  zero,  one,  or  more  sets  in  a  database. 

A  set  consists  of  an  owner  record,  whose  Crecord  type>  is  the  owner  Crecord  type>,  and  zero,  one,  or  more 
member  records,  each  of  whose  Crecord  type>  is  a  member  Crecord  type>. 

A  set  is  identified  uniquely  in  a  database  by  its  Cset  name>  and  its  owner  record  occurrence.  When  an  occur¬ 
rence  of  the  owner  Crecord  type>  of  a  Cset  type>  is  stored  in  the  database,  a  new  set  of  that  Cset  type>  is 
created. 

When  an  occurrence  of  Crecord  type>  is  stored  in  the  database,  it  belongs  to  at  most  one  set  of  each  Cset 
type>  in  which  the  Crecord  type>  is  a  member  Crecord  type>. 

The  member  records  of  each  set  of  a  Cset  type>  are  maintained  in  a  sequential  order  determined  by  the 
ordering  criteria  for  that  Cset  type>. 


4.4.1  Singular  sets 

A  singular  Cset  type>  is  a  Cset  type>  having  SYSTEM  as  its  owner  Crecord  type>.  A  singular  set  is  the 
unique  occurrence  of  a  singular  Cset  type>. 

4.4.2  Recursive  sets 

A  recursive  Cset  type>  is  a  set  type  having  the  same  Crecord  type>  as  both  the  owner  Crecord  type>  and  as 
a  member  Crecord  type>.  A  recursive  set  is  an  occurrence  of  a  recursive  Cset  type>. 


4.5  Schema 

A  Cschema>  is  a  persistent  object  specified  by  the  schema  definition  language.  The  Cschema>  is  a  logical 
description  of  the  database.  A  C schema >  consists  of  a  C schema  name>,  a  collection  of  Crecord  type> 
descriptions,  and  a  collection  of  Cset  type>  descriptions. 
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4.6  Subschemas 

A  <subschema>  is  a  persistent  object  specified  by  the  subschema  definition  language.  The  <subschema>  is  a 
logical  description  of  that  portion  of  a  database  available  to  an  accessing  <module>.  A  <subschema>  con¬ 
sists  of  a  <subschema  name>,  a  collection  of  <record  view>s,  and  a  collection  of  <set  view>s. 

A  <record  view>  specifies  the  available  <component  type>s  of  a  given  <record  type>.  A  <set  view>  speci¬ 
fies  an  available  <set  type>.  The  <record  view>s  and  <set  view>s  taken  together  determine  the  available 
member  <  record  type>s  of  each  <set  type>. 

The  <record  view>s  and  <set  view>s  may  define  alias  Ccomponent  view  name>s,  <record  view  name>s  and 
<set  view  name>s  for  <component  type>s,  <record  type>s,  and  <set  type>s.  The  ahas  names  become  the 
only  names  available  for  those  Ccomponent  type>s,  Crecord  type>s,  and  <set  type>s  to  an  accessing 
<  module  >. 

The  records  available  to  an  accessing  <  module  >  are  maintained  in  an  implementor-defined  order.  This  order 
is  not  necessarily  the  same  as  the  implementor-defined  order  of  the  records  of  each  Crecord  type>. 


4.7  Database 

A  database  is  the  collection  of  all  data  defined  by  a  Cschema>.  It  consists  of  the  occurrences  of  each  Crecord 
type>  and  each  Cset  type>.  There  is  exactly  one  database  for  each  C  schema  >  definition. 


4.8  Modules 

A  C module >  is  a  persistent  object  specified  in  the  module  language.  A  C module >  consists  of  an  optional 
Cmodule  name>,  a  Clanguage  clause>,  a  Csubschema  specification >,  an  optional  Ctemporary  set  specifica¬ 
tions;^  and  one  or  more  Cprocedure>s. 

An  application  program  is  a  segment  of  executable  code,  possibly  consisting  of  multiple  sub-programs.  A 
single  C  module  >  is  associated  with  an  application  program  during  its  execution.  An  application  program  shall 
be  associated  with  at  most  one  C  module  >.  The  manner  in  which  this  association  is  specified,  including  the 
possible  requirement  for  execution  of  some  implementor-defined  statement,  is  implementor-defined. 


4.9  Procedures 

A  <procedure>  consists  of  a  <procedure  name>,  an  optional  sequence  of  <parameter  declarations,  and  an 
optional  sequence  of  <NDL  statements. 

An  application  program  associated  with  a  <module>  may  reference  the  <procedure>s  of  that  <module>  by  a 
"call"  statement  that  specifies  the  <procedure  name>  of  the  <procedure>  and  supplies  a  sequence  of  param¬ 
eter  values  corresponding  in  number  and  in  <data  type>  to  the  <parameter  declarations  of  the  procedure.  A 
call  of  a  <procedure>  causes  the  sequence  of  <NDL  statements  that  it  contains  to  be  executed. 

The  <subschema  specification >  of  a  <module>  specifies  the  <subschema>  that  defines  the  records  and  sets 
that  can  be  referenced  by  the  <module>. 

The  <temporary  set  specifications >  of  a  <module>  defines  temporary  <set  type>s  that  may  be  referenced  by 
the  <  module  >. 
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4.10  Standard  programming  languages 

This  standard  specifies  the  actions  of  <  procedure  >s  in  <  module  >s  when  those  <  procedure  >s  are  called  by 
programs  that  conform  to  specified  standard  programming  languages.  The  terms  "standard  COBOL  program", 
"standard  FORTRAN  program",  "standard  Pascal  program",  and  "standard  PL/I  program"  refer  to  programs 
that  meet  the  conformance  criteria  of  the  standards  listed  in  clause  2,  “References”  on  page  3. 


4.11  Temporary  sets 

A  <  temporary  set>  is  an  occurrence  of  a  temporary  <set  type>.  A  temporary  <set  type>  is  declared  by  a 
<  temporary  set  specification  >  in  a  <  module  >. 

For  each  <temporary  set  specification >  in  a  <module>,  an  occurrence  of  the  corresponding  temporary  <set 
type>  is  created  when  the  <  module  >  is  initiated  and  destroyed  when  the  <  module  >  is  terminated. 


4.12  Parameters 

A  parameter  is  declared  in  a  <procedure>  by  a  <parameter  declarations  The  <parameter  declaration> 
specifies  whether  the  parameter  is  an  elementary  data  item  or  an  array  of  data  items,  and  specifies  the  <data 
type>  of  its  values.  A  parameter  either  assumes  or  supplies  the  value  or  values  of  the  corresponding  argument 
in  the  call  of  that  procedure. 


4.12.1  STATUS  parameter 

The  STATUS  parameter  is  a  special  parameter  of  <length>  5  characters.  If  such  a  parameter  is  declared  in  a 
<procedure>,  then  its  value  is  set  to  a  status  code  that  either  indicates  that  a  call  of  the  <  procedure  >  was 
successfully  completed  or  that  identifies  an  exception  condition  that  occurred  dining  execution  of  the  <  proce¬ 
dure  >. 


4.12.2  TEST  parameter 

The  TEST  parameter  is  a  special  parameter  of  <length>  1  character.  If  a  test  statement  is  executed  in  a  <pro- 
cedure>  containing  this  parameter,  then  the  value  of  the  parameter  is  set  to  "1"  if  the  test  is  true,  and  to  "0"  if 
the  test  is  false. 


4.12.3  RECORD  parameter 

The  RECORD  parameter  is  a  special  parameter  of  <length>  18  characters.  If  such  a  parameter  is  declared  in 
a  <  procedure  >,  then  it  is  set  to  the  <  record  name>  of  the  record  identified  by  the  <  session  cursor  >  of  the 
<  session  state  >. 


4.  Concepts  1 3 


AMERICAN  NATIONAL  STANDARD  X3. 133-1986 


4.13  Session 

A  database  operation  is  the  execution  of  an  <NDL  statements 

A  session  is  the  sequence  of  database  operations  performed  during  the  execution  of  an  application  program 
associated  with  a  <module>. 

A  <  session  state  >  is  an  ephemeral  object  associated  with  a  session.  A  <  session  state  >  is  created  prior  to  the 
first  database  operation  in  a  session  and  is  destroyed  after  the  last  database  operation  in  the  session. 

A  <session  state>  consists  of  <cursors>,  <temporary  sets>,  and  a  <ready  list>.  The  <cursors>  include:  A 
<session  cursor>  to  identify  the  current  session  record,  a  <record  cursor>  to  identify  the  current  record  of 
each  <subschema>  <record  type>,  and  a  <set  cursor>  to  identify  the  owner  record  and  the  current  member 
record  in  the  current  set  of  each  <subschema>  <set  type>.  The  Ctemporary  sets>  maintain  the  contents  of 
each  <temporary  set>  defined  by  the  associated  <module>.  The  <ready  list>  maintains  the  <ready 
specifications  for  each  <record  type>  that  has  been  activated  by  a  <ready  statements 

The  <session  state>  is  available  to  an  application  program  only  through  <NDL  statements.  The  contents  of 
the  <  session  state  >  are  modified  by  the  database  management  system  upon  execution  of  <NDL  statement  >s 
in  a  <  procedure  >  of  its  associated  <  module  >.  The  data  manipulation  language  includes  <NDL  statement  >s 
to  find  and  compare  <database  key>s  and  to  modify  the  contents  of  the  <ready  list>  and  each  <temporary 
set>. 


4.14  Transactions 

A  transaction  is  a  sequence  of  operations,  including  database  operations,  that  is  atomic  with  respect  to  recovery 
and  concurrency.  Transactions  terminate  with  a  <commit  statement>  or  a  <rollback  statements  If  a  trans¬ 
action  terminates  with  a  <  commit  statement  >,  then  all  changes  made  to  the  database  by  that  transaction  are 
made  accessible  to  all  concurrent  transactions.  If  a  transaction  terminates  with  a  <rollback  statements  then 
all  changes  made  to  the  database  by  that  transaction  are  canceled.  Committed  changes  cannot  be  canceled. 
Changes  made  to  the  database  by  a  transaction  can  be  perceived  by  that  transaction,  but  cannot  be  perceived 
by  other  transactions  until  that  transaction  terminates  with  a  <commit  statements 

The  execution  of  concurrent  transactions  is  guaranteed  to  be  serializable.  A  serializable  execution  is  defined  to 
be  an  execution  of  the  operations  of  concurrently  executing  transactions  that  produces  the  same  effect  as  some 
serial  execution  of  those  same  transactions.  A  serial  execution  is  one  in  which  each  transaction  executes  to 
completion  before  the  next  transaction  begins. 

The  execution  of  an  <NDL  statement  >  within  a  transaction  has  no  effect  on  the  database  or  <  session  state  > 
other  than  the  effect  stated  in  the  General  Rules  for  that  <NDL  statements  Together  with  serializable  exe¬ 
cution,  this  implies  that  all  read  operations  are  reproducible  within  a  transaction,  except  for  changes  explicitly 
made  by  the  transaction  itself. 


4.15  Integrity  constraints 

Integrity  constraints  restrict  the  valid  states  of  the  database.  Integrity  constraints  may  be  defined  for  <record 
type>s  or  <set  type>s,  and  for  component  constraints  between  owner  and  member  <record  type>s. 

Integrity  constraints  are  checked  after  execution  of  each  <NDL  statements  If  the  objects  associated  with  the 
integrity  constraint  do  not  satisfy  the  constraint,  then  the  <NDL  statement>  has  no  effect  on  the  database, 
and  the  STATUS  parameter  is  set  to  indicate  the  specified  exception. 
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4.15.1  Check  conditions 

A  check  condition  is  an  expression  that  shall  be  satisfied  by  the  values  of  a  record  when  its  status  in  the  data¬ 
base  is  altered.  The  expression  is  specified  by  a  <condition>  of  a  <record  check  clause>  of  a  <record  type> 
or  a  <  member  check  clause  >  of  a  <set  type>. 

4.15.2  Default  values 

A  default  value  is  a  value  to  be  assumed  by  all  component  occurrences  in  the  absence  of  an  explicit  value  sup¬ 
plied  by  a  <  procedure  >.  A  default  value  is  specified  by  a  <  literal  >  in  a  <  default  clause  >  of  a  <  component 
type>. 

4.15.3  Uniqueness  constraints 

A  uniqueness  constraint  is  a  specification  that  no  two  records  of  a  given  <  record  type>,  or  no  two  member 
records  of  a  set  of  a  given  <set  type>,  may  occur  in  the  database  with  identical  values  for  specified  compo¬ 
nents.  Uniqueness  constraints  are  specified  by  <record  uniqueness  clause>s  in  a  <record  type>,  or  by 
<  member  uniqueness  clause  >s  in  a  <  member  clause  >  of  a  <set  type>. 

4.15.4  Set  ordering  criteria 

A  set  ordering  specifies  the  sequential  ordering  of  member  records  in  a  set.  The  ordering  is  one  of  the  fol¬ 
lowing: 

1 )  Sorted  by  component  values 

2)  Chronological  or  reversed  chronological 

3)  Relative  positioning  as  next  or  prior  to  a  given  member  record 

4)  Implementor-defined 

Set  ordering  criteria  are  specified  by  the  <  order  clause  >  of  a  <set  type>,  and  if  the  order  is  sorted,  by  the 
<key  clause>  of  each  <member  clause>  contained  in  that  <set  type>. 

4.15.5  Set  membership 

Set  membership  specifies  the  insertion  and  retention  modes  of  a  record  for  each  set  in  which  it  occurs  as  a 
member  record.  Each  member  < record  type>  has  an  insertion  mode  and  a  retention  mode. 

Insertion  is  either  automatic,  structural,  or  manual.  If  insertion  is  manual,  then  records  shall  be  inserted  as 
member  records  in  a  set  only  by  an  explicit  <  connect  statement  >.  If  insertion  is  automatic  or  structural,  then 
each  record  of  a  member  <  record  type>  becomes  a  member  of  some  set  of  that  <set  type>  when  it  is  initially 
stored  in  the  database.  If  insertion  is  automatic  or  manual,  then  the  owner  record  is  identified  by  the  applica¬ 
tion  program.  If  insertion  is  structural,  then  the  owner  record  is  selected  by  the  database  management  system 
to  have  values  of  specified  data  items  equal  to  those  of  the  record  to  be  inserted.  The  insertion  mode  is  speci¬ 
fied  by  an  < insertion  clause>  in  each  <member  clause>  of  the  < schema >. 

Retention  is  either  fixed,  mandatory,  or  optional.  If  retention  is  fixed,  then  a  record,  having  once  become  a 
member  record  of  some  set,  remains  a  member  of  that  set  until  it  is  erased  from  the  database.  If  retention  is 
mandatory,  then  a  record,  having  once  become  a  member  record  of  a  set,  remains  a  member  of  some  set  of  the 
same  <set  type>  until  it  is  erased  from  the  database.  If  retention  is  optional,  then  a  record,  having  once 
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become  a  member  record  of  some  set,  need  not  remain  a  member  of  that  set  or  of  any  set  of  that  <set  type>. 
The  retention  mode  is  specified  by  a  <retention  clause>  in  each  <member  clause>  of  the  < schema >. 
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5.  Common  elements 


5.1  <  condition  > 

Function 

Specify  an  expression  that  shall  be  evaluated  as  either  true  or  false. 

Format 

<condition>  ::  = 

< alternative >  [{OR  < alternative >}...] 

< alternative >  ::  = 

<simple  condition>  [{AND  <simple  condition>}...] 

< simple  condition >  ::  = 

<  subcondition  > 

|  <  negated  subcondition  > 

|  <  relation  condition  > 

<subcondition>  ::=  (<condition>) 

< negated  subcondition>  ::  = 

NOT  (  <  condition  >  ) 

<  relation  condition  >  ::  = 

<operand>  <relation>  <operand> 


<  relation  >  ::  = 

<  I  <=  I  =  I  >=  I  >  I  <> 

Syntax  Rules 

1)  If  the  first  <operand>  in  a  <relation  condition>  specifies  an  array,  then  the  second  <operand>  in  that 
<relation  condition>  shall  not  specify  an  array. 

2)  If  the  type  of  the  first  operand  is  character  string,  then  the  type  of  the  second  operand  shall  be  character 
string.  If  the  type  of  the  first  operand  is  exact  numeric,  then  the  type  of  the  second  operand  shall  be  exact 
numeric  or  approximate  numeric.  If  the  type  of  the  first  operand  is  approximate  numeric,  then  the  type  of 
the  second  operand  shall  be  exact  numeric  or  approximate  numeric. 

General  Rules 

1)  A  <condition>  is  true  if  any  <altemative>  contained  in  it  is  true',  otherwise,  it  is  false. 

2)  An  <altemative>  is  true  if  every  <simple  condition>  contained  in  it  is  true',  otherwise,  it  is  false. 

3)  A  <simple  condition>  that  immediately  contains  a  < subcondition >  is  true  if  the  < subcondition >  is  true', 
otherwise,  it  is  false. 
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A  <simple  condition>  that  immediately  contains  a  Cnegated  subcondition>  is  true  if  the  <condition> 
immediately  contained  in  the  <  negated  subcondition>  is  false]  otherwise,  it  is  false. 

A  <  simple  condition  >  that  immediately  contains  a  <relation  condition  >  is  true  if  the  <  relation  condi- 
tion>  is  true ;  otherwise,  it  is  false. 

4)  The  first  (second)  operand  of  a  <relation  condition>  is  the  value  of  the  first  (second)  <operand>  in  that 
<  relation  condition  >. 

5)  The  <relation>  of  a  <relation  condition>  specifies  a  comparison  to  be  made  between  the  two  operands  of 
the  <relation  conditions  The  comparisons  specified  by  the  alternative  <relation>s  are  as  follows: 


elation  > 

Comparison 

< 

less  than 

<  = 

less  than  or  equal 

= 

equal 

<> 

not  equal 

> 

greater  than 

>  = 

greater  than  or  equal 

6)  If  neither  operand  of  a  <relation  condition>  is  an  array,  then  the  <relation  condition>  is  true  if  the  speci¬ 
fied  comparison  of  the  two  operands  is  true ;  otherwise,  the  <re!ation  condition>  is  false.  If  one  of  the 
operands  of  a  <  relation  condition  >  is  an  array,  then  the  <  relation  condition  >  is  true  if  the  specified  com¬ 
parison  of  every  value  in  the  array  sequence  with  the  other  operand  is  true ;  otherwise,  the  <relation  condi- 
tion>  is  false. 

7)  Case: 


a)  If  operands  are  of  exact  numeric  or  approximate  numeric  type,  then  the  comparison  is  performed 

according  to  their  numeric  values. 

b)  If  the  operands  are  of  character  string  type,  then: 

i)  If  the  lengths  of  the  two  operands  are  not  equal,  then  the  shorter  operand  is  considered  to  be 
extended  on  the  right  with  space  characters. 

ii)  The  comparison  is  performed  from  left  to  right,  comparing  the  individual  characters  of  the  oper¬ 
ands.  If  all  such  individual  comparisons  are  equal,  then  the  two  operands  are  equal;  otherwise,  the 
result  of  the  comparison  of  the  operands  is  defined  to  be  the  result  of  the  leftmost  nonequal  com¬ 
parison  of  the  individual  characters. 

iii)  The  comparison  of  individual  characters  is  implementor-defined. 


8) 


In  General  Rules,  the  terms  "less  than", 
sponding  relational  operators. 


"greater  than",  "equal",  and  "not  equal"  refer  to  the  corre- 
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5.2  < operand > 

Function 

Specify  a  value. 

Format 

< operand >  = 

<  component  identifier > 

|  <component  view  identifier> 

|  <parameter  identifier> 

|  <  literal  > 

Syntax  Rules 

1)  Case: 

a)  If  an  <operand>  is  contained  in  a  <schema>,  then  it  shall  not  be  a  <parameter  identifier>  or  a 
<  component  view  identifier  >. 

b)  If  an  <operand>  is  contained  in  a  <module>,  then  it  shall  not  be  a  Ccomponent  identifiers 

2)  The  data  type  of  an  <operand>  is  the  data  type  of  the  Ccomponent  identifiers  Ccomponent  view  identi¬ 
fiers  Cparameter  identifier >,  or  Cliterals 

General  Rules 

1)  The  value  of  an  Coperand>  is  the  data  item  or  array  referenced  by  the  Ccomponent  identifiers  Ccompo¬ 
nent  view  identifiers  or  Cparameter  identifiers  or  the  value  of  the  Cliterals 
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5.3  < identifier > 

Function 

Specify  names  for  parameters  in  a  < procedure >  or  objects  in  the  database. 

Format 

<identifier>  ::  = 

Cregular  identifier>  |  <escape  identifier> 

< regular  identifier>  ::  = 

<  upper  case  letter > 

[{[<underscore>]  <letter  or  digit> }...] 

< underscore >  _ 

<  letter  or  digit  >  ::  = 

<  upper  case  letter >  |  <  digit  > 

<  letter  >  ::  = 

<  upper  case  letter  >  |  <  lower  case  letter  > 

<upper  case  letter>  ::  = 

A|B|C|D|E|F|G|H|I 
|  J|K|L|M|N|0|P|Q|R 
|  S  |  T  |  U  |  V|  W|X|  Y|Z 

<lower  case  letter>  ::  = 

a | b | c | d | e | f |g|h|i 
|  j|k|l|m|n|o|p|q|r 
|s|t|u|v|w|x|y|z 

< digit >  ::  = 

0| 1 |2|3|4|5|6|7|8|9 
<escape  identifier>  ::  = 

’<escape  identifier  character  representation >...’ 

< escape  identifier  character  representation >  ::  = 

<escape  identifier  character> 

|  <  apostrophe  representation  > 

<escape  identifier  character>  ::  = 

See  Syntax  Rule  3. 

< apostrophe  representation>  ” 
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Syntax  Rules 

1)  A  Cregular  identifier>  shall  contain  at  most  18  characters.  An  <escape  identifier>  shall  contain  at  most 
18  <escape  identifier  character  representation >s. 

2)  A  <regular  identifier>  shall  not  be  the  same  sequence  of  characters  as  a  <key  word>  (see 
5.8,  “Comments,  spaces,  and  key  words”  on  page  28). 

3)  An  <escape  identifier  character>  is  any  character  in  the  implementor-defined  character  set  other  than  the 
apostrophe  character  (’)• 

4)  Each  <apostrophe  representation >  in  an  <escape  identifier>  represents  a  single  apostrophe  character. 

5)  If  an  <escape  identifier>  (apart  from  the  enclosing  apostrophes)  conforms  to  the  format  of  a  Cregular 
identifier^  and  if  it  is  not  a  <key  word>,  then  it  is  equivalent  to  the  Cregular  identifier>  formed  by 
removing  the  enclosing  apostrophes. 

General  Rules 

None. 
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5.4  <literal> 

Function 

Specify  a  literal  value. 

Format 

<  literal  >  ::  = 

<  character  string  literal  > 

|  <  numeric  literal  > 

<character  string  literal>  ::  = 

' '  <  character  representation> . . . " 

< character  representation >  ::  = 

<  nonquote  character  > 

|  <  quote  representation  > 

< nonquote  character >  ::  = 

See  Syntax  Rule  1 . 

< quote  representation >  = 


< numeric  literal >  ::  = 

<  exact  numeric  literal  > 

|  <  approximate  numeric  literal  > 

< exact  numeric  literal >  ::  = 

[+  |  -]  {  Cunsigned  integer>[.<unsigned  integer>] 
|  <unsigned  integer>. 

|  .  <  unsigned  integer  > } 

< approximate  numeric  literal >  ::  = 

<  mantissa  >  E  <  exponent  > 

<mantissa>  ::=  <exact  numeric  literal> 

<exponent>  ::=  <signed  integer> 

<signed  integer>  ::=  [+  I  -]  Cunsigned  integer> 

Cunsigned  integer >  ::  = 

Cdigit>... 
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Syntax  Rules 

1)  A  <  nonquote  character  >  is  any  character  in  the  implementor-defined  character  set  other  than  the  double 
quote  mark  character  ("). 

2)  The  data  type  of  a  <  character  string  literal  >  is  character  string.  The  length  of  a  <  character  string  literal  > 
is  the  number  of  <character  representation >s  that  it  contains.  Each  <quote  representation>  in  a  <char- 
acter  string  literal  >  represents  a  single  quotation  mark  character  in  both  the  value  and  the  length  of  the 

<  character  string  literal  >. 

3)  An  < exact  numeric  literal >  without  a  decimal  point  (.)  has  an  implied  decimal  point  following  the  last 

<  digit  >. 

4)  The  data  type  of  an  <exact  numeric  literal>  is  exact  numeric.  The  precision  of  an  <exact  numeric  literal> 
is  the  number  of  <digit>s  that  it  contains.  The  scale  of  an  <  exact  numeric  literal  >  is  the  number  of 
<digit>s  to  the  right  of  the  decimal  point. 

5)  The  data  type  of  an  approximate  numeric  literal>  is  approximate  numeric.  The  precision  of  an  Approx¬ 
imate  numeric  literal  >  is  the  number  of  binary  digits  required  to  represent  the  significant  digits  of  its 
mantissa. 

General  Rules 

1)  The  value  of  a  <  character  string  literal  >  is  the  sequence  of  characters  that  it  contains. 

2)  The  numeric  value  of  an  <unsigned  integer>,  <signed  integer>,  or  <exact  numeric  literal>  is  derived 
from  the  normal  mathematical  interpretation  of  signed  positional  decimal  notation. 

3)  The  numeric  value  of  an  <  approximate  numeric  literal  >  is  the  product  of  the  exact  numeric  value  repres¬ 
ented  by  the  <  mantissa  >  with  the  number  obtained  by  raising  the  number  10  to  the  power  represented  by 
the  <  exponent  >. 
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5.5  <data  type> 

Function 

Specify  a  data  type. 

Format 

<data  type>  ::  = 

<  character  string  type> 

|  <  exact  numeric  type> 

|  <  approximate  numeric  type> 

< character  string  type>  ::  = 

CHARACTER  [<length>] 

< exact  numeric  type>  ::  = 

FIXED  <  precision  >  [<  scale  >] 

|  NUMERIC  <  precision  >  [<  scale  >] 

|  INTEGER 

< approximate  numeric  type>  ::  = 

FLOAT  <  precision  > 

|  REAL 

|  DOUBLE  PRECISION 
< length >  ::=  < unsigned  integer > 

<precision>  ::=  < unsigned  integer > 

< scale >  ::=  < signed  integer > 

Syntax  Rules 

1)  The  value  of  an  <unsigned  integer>  that  is  a  <length>  or  a  <precision>  shall  be  greater  than  0. 

2)  If  a  <length>  is  omitted,  then  it  is  assumed  to  be  1.  If  a  <scale>  is  omitted,  then  it  is  assumed  to  be  0. 

General  Rules 

1)  A  <data  type>  specifies  a  class  of  data  item  values. 

2)  A  data  item  of  <data  type>  CHARACTER  has  a  character  string  value  with  length  equal  to  the  value  of 
the  specified  <  length  >. 

3)  A  data  item  of  <data  type>  FIXED  has  an  exact  numeric  value  with  scale  equal  to  the  value  of  the  speci¬ 
fied  <scale>,  and  with  precision  greater  than  or  equal  to  the  value  of  the  specified  <precision>. 

4)  A  data  item  of  <data  type>  NUMERIC  has  an  exact  numeric  value  with  precision  and  scale  equal  respec¬ 
tively  to  the  value  of  the  specified  <precision>  and  <scale>.  If  the  precision  is  P  and  the  scale  is  S,  then 
the  absolute  value  of  any  nonzero  NUMERIC  data  item  shall  be  greater  than  or  equal  to  1E-S  and  less 
than  or  equal  to  1E(P-S)-1E-S. 
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5)  A  data  item  of  <data  type>  INTEGER  has  an  exact  numeric  value  with  a  scale  of  0  and  with 
implementor-defined  precision. 

6)  A  data  item  of  <data  type>  FLOAT  has  an  approximate  numeric  value  with  binary  precision  equal  to  or 
greater  than  the  value  of  the  specified  <precision>. 

7)  A  data  item  of  <data  type>  REAL  has  an  approximate  numeric  value  with  implementor-defined  precision. 

8)  A  data  item  of  <data  type>  DOUBLE  PRECISION  has  an  approximate  numeric  value  with  implementor- 
defined  precision  that  is  greater  than  the  implementor-defined  precision  of  REAL. 
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5.6  < occurs  clause > 

Function 

Define  an  array  by  specifying  its  <extents>. 

Format 

< occurs  clause >  ::  = 

OCCURS  <extents> 

<extents>  < unsigned  integer >... 

Syntax  Rules 

1)  The  value  of  each  <unsigned  integer>  in  the  <extents>  shall  be  greater  than  0. 

General  Rules 

1)  An  <  occurs  clause  >  specifies  an  array  of  data  items.  The  product  of  the  values  of  the  <  unsigned 
integer >s  in  the  <  extents  >  specifies  the  number  of  data  items  contained  in  each  occurrence  of  the  array. 
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5.7  < subscripts > 

Function 

Specify  a  data  item  of  an  array. 

Format 

< subscripts >  ::  = 

(<operand>...) 

Syntax  Rules 

1)  The  contextual  <  occurs  clause  >  of  a  <  subscripts  >  is  specified  in  the  Syntax  Rules  of  the  production 
symbol  that  immediately  contains  the  <  subscripts  >. 

2)  The  number  of  < operand >s  shall  be  equal  to  the  number  of  <  unsigned  integer >s  in  the  <extents>  of  the 
contextual  <  occurs  clause  >. 

3)  Case: 

a)  If  an  < operand >  is  a  < literal >,  then  it  shall  be  an  <unsigned  integer >  whose  value  is  positive  and  is 
not  greater  than  the  value  of  the  corresponding  <unsigned  integer>  of  the  <extents>  of  the  contex¬ 
tual  <  occurs  clause  >. 

b)  If  an  < operand >  is  not  a  < literal >,  then  its  data  type  shall  be  exact  numeric  with  a  scale  of  0. 

General  Rules 

1)  Let  d  be  the  number  of  <  operand  >s  in  the  <  subscripts  >. 

2)  For  i  from  1  to  d,  let  Si  be  the  value  of  the  i-th  <operand>  in  the  <subscripts>. 

3)  For  i  from  1  to  d,  let  Ei  be  the  value  of  the  i-th  < unsigned  integer>  in  the  < extents >  of  the  contextual 
<  occurs  clause  >. 

4)  For  i  from  1  to  d,  if  Si  is  less  than  1  or  Si  is  greater  than  Ei,  then  raise  exception  array  reference:  subscript 
out  of  bounds. 

5)  Let  Md  be  1.  For  i  from  1  to  (d-1),  let  Mi  be  the  product  of  the  terms  Ej,  for  j  from  (i+ 1)  to  d. 

6)  Let  J  be  the  sum  of  the  terms  Mi* (Si-1),  for  i  from  1  to  d. 

7)  The  value  of  the  < subscripts >  is  J+l. 
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5.8 


Comments,  spaces,  and  key  words 


I 


Function 

Specify  lexical  units. 

Format 

<separator>  ::  = 

{  <comment>  |  <space>  |  <newline>  }... 

< comment >  ::  = 

(*[<character>...]*) 

< character >  ::  = 

<digit>  |  < letter >  |  < special  character > 

< special  character >  ::  = 

See  Syntax  Rule  1 . 


<space>  ::  = 

space  character 

< newline >  ::  = 

implementor-defined  end-of-line  indicator 

<word>  ::  = 

<key  word>  |  <identifier>  |  <literal> 


<key  word>  ::  = 

ABSOLUTE  |  ALL  |  AND  |  AS  |  ASCENDING  |  AUTOMATIC 
|  CASCADE  |  CHARACTER  |  CHECK  |  COBOL 
|  COMMIT  |  CONNECT  |  CONTAINS 

|  DEFAULT  |  DESCENDING  |  DISCONNECT  |  DOUBLE  |  DUPLICATES 
|  EMPTY  |  ERASE  |  EXCLUSIVE 

[  FIND  |  FINISH  |  FIRST  |  FIXED  |  FLOAT  |  FOR  |  FORTRAN  |  FROM  |  FULL 
|  GET  |  IN  |  INSERTION  |  INTEGER  |  ITEM  |  KEY  |  LANGUAGE  |  LAST 
|  MANDATORY  |  MANUAL  |  MEMBER  |  MODIFY  |  MODULE 
|  NEXT  |  NOT  |  NULL  |  NULLIFY  |  NUMERIC 
|  OCCURS  |  OF  |  OPTIONAL  |  OR  |  ORDER  |  OWNER 
|  PARTIAL  |  PASCAL  |  PLI  |  PRECISION 
|  PRIOR  |  PROCEDURE  |  PROHIBITED  |  PROTECTED 
|  READY  |  REAL  |  RECONNECT  |  RECORD  |  RELATIVE  |  RENAMED 
|  RETAIN  |  RETENTION  |  RETRIEVE  |  ROLLBACK 
|  SCHEMA  |  SESSION  |  SET  |  SHARED  |  SORTED 
|  STATUS  |  STORE  |  STRUCTURAL  |  SUBSCHEMA  |  SYSTEM 
|  TEST  |  TO  |  TYPE  |  UNIQUE  |  UPDATE  |  WHERE  |  WITH 


I 
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Syntax  Rules 

1)  A  <special  character>  is  any  character  in  the  implementor-defined  character  set  other  than  a  <digit>  or  a 
<letter>.  If  the  implementor-defined  end-of-line  indicator  (<newline>)  is  a  character,  then  it  is  also 
excluded  from  <special  characters 

2)  A  terminal  production  of  <schema>,  <subschema>,  or  <module>  consists  of  a  sequence  of  <word>s 
and  symbols  optionally  separated  by  <separator>s.  A  <word>  shall  not  be  immediately  followed  by 
another  <word>  without  an  intervening  <separator>. 

3)  The  string  "< characters.."  within  a  < comment >  shall  not  contain  the  substring 

General  Rules 

None. 
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6.  Schema  definition  language 
6.1  <schema> 

Function 

Define  the  logical  structure  of  a  database. 

Format 

< schema >  ::  = 

<  schema  name  clause  > 

[  {<record  type>  |  <set  type>}...] 

Syntax  Rules 

None. 

General  Rules 

None. 
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6.2  <  schema  name  clause > 

Function 

Name  a  <schema>. 

Format 

< schema  name  clause >  ::  = 

SCHEMA  <schema  name> 

< schema  name>  ::=  < identifier > 

Syntax  Rules 

1)  The  <schema  name>  shall  be  different  from  the  <schema  name>  of  any  other  <schema>  in  the  same 
environment.  The  concept  of  environment  is  implementor-defined. 

General  Rules 

1)  A  <schema  name  clause>  defines  the  <identifier>  to  be  a  <schema  name>  that  designates  the  containing 
<schema>. 
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6.3  <  record  type> 

Function 

Define  a  <  record  type>. 

Format 

< record  type >  ::  = 

<  record  name  clause  > 

[  {  <  record  uniqueness  clause  > 

|  <  component  type> 

|  < record  check  clause >}...] 

Syntax  Rules 

None. 

General  Rules 

None. 
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6.4  < record  name  clause > 

Function 

Name  a  <  record  type>. 

Format 

< record  name  clause >  ::  = 

RECORD  <record  name> 

<record  name>  ::=  <identifier> 

Syntax  Rules 

1)  The  <record  name>  shall  be  different  from  the  Crecord  name>  of  any  other  <record  name  clause>  in 
the  containing  <  schema  >. 

General  Rules 

1)  A  Crecord  name  clause>  defines  the  <identifier>  to  be  a  Crecord  name>  that  designates  the  containing 
Crecord  type>. 
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6.5  < record  uniqueness  clause > 

Function 

Specify  a  uniqueness  constraint  for  occurrences  of  a  <record  type>. 

Format 

< record  uniqueness  clause >  ::  = 

UNIQUE  < component  identifier >... 

Syntax  Rules 

1)  If  the  <component  name>  of  a  <component  identifier>  designates  an  array,  then  that  <component  iden¬ 
tified  shall  contain  <subscripts>. 

2)  A  given  <component  identified  shall  be  contained  at  most  once  in  a  single  <record  uniqueness  clause>. 

3)  The  contextual  <record  type>  of  each  <component  identified  in  a  <record  uniqueness  clause>  is  the 
containing  <  record  type>. 

General  Rules 

1)  When  the  < component  identifieds  of  a  <record  uniqueness  clause>  are  referenced  for  a  record  occur¬ 
rence,  the  contextual  <database  key>  for  those  <component  identifier>s  is  the  <database  key>  of  that 
record  occurrence. 

2)  A  <  record  uniqueness  clause  >  is  violated  if  the  database  contains  two  occurrences  of  the  containing 
Crecord  type>  in  which  the  values  of  each  of  the  components  designated  by  the  <component  identifieds 
in  the  <record  uniqueness  clause>  in  the  first  record  occurrence  are  equal  to  the  values  of  the  corre¬ 
sponding  components  in  the  second  record  occurrence. 
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6.6  <  component  type> 

Function 

Define  a  <  component  type>. 

Format 

<  component  type  >  ::  = 

<  component  name  clause  > 
<data  type> 

[<  occurs  clause  >] 

[<  default  clause  >] 

Syntax  Rules 

None. 

General  Rules 

None. 
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6.7  <  component  name  clause  > 

Function 

Name  a  <component  type>. 

Format 

< component  name  clause >  ::=  ITEM  < component  name> 

Ccomponent  name>  ::=  <identifier> 

Syntax  Rules 

1)  The  Ccomponent  name>  shall  be  different  from  the  Ccomponent  name>  of  any  other  Ccomponent  name 
clause  >  in  the  containing  C  record  type>. 

General  Rules 

1)  A  Ccomponent  name  clause >  defines  the  C identifier >  to  be  a  Ccomponent  name>  that  designates  the 
containing  Ccomponent  type>. 
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6.8  < default  clause > 

Function 

Specify  a  default  value  for  a  <component  type>. 

Format 

< default  clause >  ::  = 

DEFAULT  <  literal  > 

Syntax  Rules 

1)  The  subject  <data  type>  of  a  <default  clause>  is  the  <data  type>  of  the  containing  <component  type>. 

2)  Case: 

a)  If  the  subject  <data  type>  defines  character  string  values,  then  the  <literal>  shall  be  a  <character 
string  literal  >.  The  length  of  the  <  character  string  literal  >  shall  not  be  greater  than  the  value  of  the 

<  length  >  of  the  subject  <data  type>. 

b)  If  the  subject  <data  type>  defines  exact  numeric  values,  then  the  <literal>  shall  be  an  <exact 
numeric  literal  >.  The  number  of  significant  digits  to  the  right  of  the  decimal  point  shall  not  be  greater 
than  the  <scale>  of  the  subject  <data  type>.  The  number  of  significant  digits  to  the  left  of  the 
decimal  point  shall  not  be  greater  than  P-S,  where  P  and  S  are  respectively  the  <precision>  and 

<  scale  >  of  the  subject  <data  type>. 

c)  If  the  subject  <data  type>  defines  approximate  numeric  values,  then  the  <literal>  shall  be  an 

<  approximate  numeric  literal  >  or  an  <  exact  numeric  literal>.  The  number  of  binary  digits  required 
to  represent  the  significant  digits  shall  not  be  greater  than  the  <precision>  of  the  subject  <data 
type>. 

General  Rules 

1)  When  an  occurrence  of  the  containing  <record  type>  is  stored  by  a  <store  statement>,  the  value  of  each 
data  item  contained  in  the  occurrence  of  the  containing  < component  type>  is  as  follows: 

Case: 

a)  If  the  <literal>  is  an  <exact  numeric  literal>,  then  the  value  is  the  exact  numeric  value  of  the 

<  literal  >. 

b)  If  the  <literal>  is  an  Approximate  numeric  literal>,  then  the  value  is  the  approximate  numeric  value 
of  the  <  literal  >. 

c)  If  the  <literal>  is  a  <character  string  literal>  and  the  length  of  the  <literal>  is  equal  to  the  length  of 
the  subject  <data  type>,  then  the  value  is  the  <literal>. 

d)  If  the  <literal>  is  a  <character  string  literal>  and  the  length  of  the  <literal>  is  less  than  the  length  of 
the  subject  <data  type>,  then  the  value  is  the  <  character  string  literal>,  extended  on  the  right  to  the 
length  of  the  subject  component  with  space  characters. 
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6.9  < record  check  clause > 

Function 

Specify  a  validity  condition  for  occurrences  of  a  <record  type>. 

Format 

<  record  check  clause  >  ::  = 

CHECK  <  condition  > 

Syntax  Rules 

1)  The  contextual  <record  type>  of  each  <component  identifier>  in  the  <condition>  is  the  containing 
Crecord  type>. 

General  Rules 

1)  When  the  <condition>  of  a  <record  check  clause>  is  evaluated  for  a  record  occurrence,  the  contextual 
<database  key>  for  any  <component  identifier>  in  the  <condition>  is  the  <database  key>  of  that 
record  occurrence. 

2)  A  Crecord  check  clause>  is  violated  if  the  database  contains  a  record  occurrence  of  the  containing 
Crecord  type>  for  which  the  Ccondition>  is  false. 
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6.10  <settype> 

Function 

Define  a  <set  type>. 

Format 

<set  type>  ::  = 

<set  name  clause  > 

<  owner  clause  > 

<  order  clause  > 

< member  clause  >... 

Syntax  Rules 

None. 

General  Rules 

None. 
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6.11  <  set  name  clause  > 

Function 

Name  a  <set  type>. 

Format 

<set  name  clause >  ::  = 

SET  <set  name> 

<set  name>  ::=  < identifier > 

Syntax  Rules 

1)  The  <set  name>  shall  be  different  from  the  <set  name>  of  any  other  <set  name  clause>  in  the  con¬ 
taining  <  schema  >. 

General  Rules 

1)  A  <set  name  clause>  defines  the  <identifier>  to  be  a  <set  name>  that  designates  the  containing  <set 
type>. 
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6.12  < owner  clause > 

Function 

Specify  the  owner  of  a  <set  type>. 

Format 

< owner  clause >  ::  = 

OWNER  {<recordname>  |  SYSTEM} 

Syntax  Rules 

1)  If  an  <  owner  clause  >  contains  a  <  record  name>,  then  that  <  record  name>  shall  designate  a  <  record 
type>  in  the  containing  <  schema  >. 

General  Rules 

1)  Case: 

a)  If  the  <owner  clause>  specifies  a  <record  name>,  then  that  <record  name>  is  the  owner  <record 
name>  of  the  containing  <set  type>,  and  the  <  record  type>  designated  by  that  <  record  name>  is 
the  owner  <record  type>  of  that  <set  type>. 

b)  If  the  <owner  clause>  specifies  SYSTEM,  then  the  containing  <set  type>  is  a  singular  <set  type> 
with  SYSTEM  as  its  owner  <  record  type>. 
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6.13  <order  clause> 

Function 

Specify  the  ordering  of  member  records  in  a  set. 

Format 

< order  clause >  ::  = 

ORDER  <  order  option  > 

< order  option >  ::  = 

FIRST 
|  LAST 
|  NEXT 
|  PRIOR 
|  DEFAULT 
1  <  sorted  order > 


< sorted  order >  ::  = 

SORTED  {<  record  type  sequence  >  |  <  order  duplicates  >} 

Crecord  type  sequence>  — 

RECORD  TYPE  < record  name>... 

< order  duplicates >  ::  = 

DUPLICATES 

{  PROHIBITED 
|  FIRST 
|  LAST 
|  DEFAULT  } 


Syntax  Rules 

1)  If  <sorted  order>  is  specified,  then  a  <key  clause>  shall  be  included  in  each  <member  clause>  of  the 
containing  <set  type>.  Otherwise,  no  <member  clause>  of  the  containing  <set  type>  shall  include  a 
<key  clause  >. 

2)  If  <record  type  sequence>  is  specified,  then  each  <record  name>  shall  designate  a  member  Crecord 
type>  of  the  containing  <set  type>,  and  every  Crecord  name>  that  designates  a  member  Crecord  type> 
of  the  containing  Cset  type>  shall  occur  exactly  once  in  the  Crecord  type  sequence >. 

3)  If  Crecord  type  sequence >  is  included,  then  the  Ckey  clause >  of  each  C member  clause >  in  the  con¬ 
taining  Cset  type>  shall  include  a  Crecord  type  key  item>;  otherwise,  no  such  Ckey  clause>  shall  include 
a  Crecord  type  key  item>. 

4)  If  Corder  duplicates>  is  specified,  then  no  Ckey  clause>  of  any  Cmember  clause>  in  the  containing  Cset 
type>  shall  include  a  Ckey  duplicates >;  otherwise,  each  Ckey  clause >  of  every  Cmember  clause >  in  the 
containing  Cset  type>  shall  include  a  Ckey  duplicates>. 
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NOTE:  Together  with  rules  governing  the  <key  clause>,  this  ensures  that  set  members  with  duplicate  key 
items  are  controlled  either  by  a  single  <  order  duplicates  >  in  the  <  order  clause  >  or  by  a  <key  duplicates  > 
in  each  < member  clause >. 

General  Rules 

1)  If  the  <  order  option  >  is  LAST  or  FIRST,  then  the  database  control  system  shall  maintain  member  records 
of  an  occurrence  of  the  containing  <set  type>  respectively  in  chronological  or  reverse  chronological  order. 
This  chronology  is  based  on  the  most  recent  time  at  which  an  <  insert  operation  >  inserts  a  member  record 
into  the  set  occurrence.  An  <insert  operation>  resulting  from  a  <modify  statement>  or  <reconnect 
statement>  that  (re)inserts  a  member  record  into  the  same  set  occurrence  establishes  a  new  point  in  the 
chronology  for  LAST  and  FIRST. 

2)  If  the  <order  option>  is  NEXT  or  PRIOR,  then  the  database  control  system  maintains  the  member 
records  of  an  occurrence  of  the  containing  <set  type>  in  an  order  determined  by  the  <  position  >  con¬ 
tained  in  the  object  <set  cursor  >  of  the  <  insert  operation  >. 

3)  If  the  <order  option>  is  DEFAULT,  then  the  database  control  system  shall  maintain  the  member  records 
of  an  occurrence  of  the  containing  <set  type>  in  an  implementor-defined  order.  This  order  is  subject  to 
the  reproducibility  requirement  within  a  transaction,  but  it  may  change  between  transactions. 

4)  If  <  sorted  order  >  is  specified,  then  the  database  control  system  shall  maintain  the  member  records  of  an 
occurrence  of  the  containing  <set  type>  in  an  order  based  on  the  sort  control  key  of  each  member  record, 
where  the  sort  control  key  of  a  member  record  consists  of  a  sequence  of  key  items  as  specified  in  the  <key 
clause  >  of  the  corresponding  <  member  clause  >  of  the  containing  <set  type>. 

5)  If  <record  type  sequence>  is  specified,  then  the  member  <record  type>s  of  the  containing  <set  type> 
shall  be  used  as  key  items  in  the  sort  control  keys  defined  in  the  <key  clause>s  of  the  <member  clause>s 
of  the  containing  <set  type>.  The  sequence  of  <record  name>s  in  the  <record  type  sequence>  specifies 
the  ascending  order  of  <record  type>s;  the  descending  order  of  <record  type>s  is  given  by  the  reverse  of 
that  sequence. 

6)  An  <  order  duplicates  >  specifies  the  action  taken  by  the  database  control  system  when  an  <  insert  opera¬ 
tion  >  would  cause  an  occurrence  of  the  containing  <set  type>  to  contain  two  or  more  member  records 
that  have  equal  values  for  all  of  the  key  items: 

Case: 

a)  If  PROHIBITED  is  specified,  then  the  <order  clause>  is  violated. 

b)  If  LAST  or  FIRST  is  specified,  then  member  records  that  have  equal  values  for  the  key  items  shall  be 
ordered  respectively  in  chronological  or  reverse  chronological  sequence.  This  chronology  is  based  on 
the  most  recent  time  that  a  <store  statement>,  <modify  statement>,  <conneet  statement>,  or 
<reconnect  statement>  inserted  a  given  member  record  into  the  set  occurrence,  or  a  <modify  state¬ 
ment  specified  values  for  one  or  more  key  items  in  the  given  member  record.  A  <modify  state¬ 
ment  >  that  specifies  values  for  one  or  more  key  items  in  a  member  record  that  are  equal  to  the  current 
values  for  those  key  items  in  that  record  establishes  a  new  point  in  the  chronology  for  <order  dupli¬ 
cates  >  FIRST  and  LAST. 

c)  If  DEFAULT  is  specified,  then  member  records  that  have  equal  values  for  all  of  the  key  items  shall  be 
ordered  in  an  implementor-defined  sequence. 

NOTE:  If  <order  duplicates>  is  not  specified,  then  the  action  to  be  taken  is  controlled  by  the  <key  dupli¬ 
cates  >  of  each  <  member  clause  >  of  the  containing  <set  type>. 
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6.14  <member  clause> 

Function 

Specify  a  member  <record  type>  of  a  <set  type>. 

Format 

< member  clause >  ::  = 

<  member  record  name  clause  > 
Cinsertion  clause > 

<  retention  clause  > 

[<member  uniqueness  clause>...] 
[<key  clause  >] 

[< member  check  clause >...] 

Syntax  Rules 

None. 

General  Rules 

None. 
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6.15  <  member  record  name  clause  > 

Function 

Specify  the  <record  name>  of  a  member  <record  type>  of  a  <set  type>. 

Format 

< member  record  name  clause >  = 

MEMBER  <  record  name> 

Syntax  Rules 

1)  The  <  record  name>  shall  designate  a  <  record  type>  in  the  containing  <  schema  >. 

2)  The  <  record  name>  shall  not  designate  any  other  member  <  record  type>  in  the  containing  <set  type>. 

General  Rules 

1)  A  Cmember  record  name  clause>  defines  the  <record  type>  designated  by  the  < record  name>  to  be  a 
member  < record  type>  of  the  containing  <set  type>  and  to  be  the  member  < record  type>  of  the  con¬ 
taining  <  member  clause  >. 
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6.16  <insertion  clause> 

Function 

Define  the  insertion  characteristics  of  a  member  <  record  type>  of  a  <set  type>. 

Format 

< insertion  clause >  ::  = 

INSERTION  <insertion  mode> 

< insertion  mode>  ::  = 

AUTOMATIC 

|  STRUCTURAL  <structural  specification > 

|  MANUAL 

< structural  specification>  ::  = 

< component  identifier  match> 

[{AND  <component  identifier  match>}...] 

< component  identifier  match>  ::  = 

<member  component  identifier>  =  <owner  component  identifier> 

|  <owner  component  identifier>  =  <member  component  identifier> 

<member  component  identifier>  ::=  <component  identifier> 

< owner  component  identifier>  ::=  <component  identifier> 

Syntax  Rules 

1)  If  the  <insertion  clause>  specifies  STRUCTURAL,  then: 

a)  If  the  <component  name>  of  a  <component  identifier>  designates  an  array,  then  that  <component 
identifier>  shall  contain  <subscripts>. 

b)  The  containing  <set  type>  shall  not  be  a  singular  <set  type>.  The  object  <record  type>  is  the 
owner  <record  type>  of  the  containing  <set  type>.  The  subject  Crecord  type>  is  the  member 
Crecord  type>  of  the  containing  <member  clause>. 

c)  If  the  subject  <record  type>  and  the  object  <record  type>  are  the  same,  then  every  <component 
identifier>  in  the  <component  identifier  match>  shall  contain  a  <qualifier>  that  specifies  either 
OWNER  or  MEMBER. 

d)  Any  <component  identifier>  in  a  <component  identifier  match>  that  contains  a  <component  name> 
that  is  defined  in  both  the  subject  Crecord  type>  and  the  object  Crecord  type>  shall  contain  a  Cqual- 
ifier>. 

e)  If  a  Ccomponent  identifier>  in  a  Ccomponent  identifier  match>  contains  a  Cqualifier>  that  specifies 
a  Crecord  name>,  then  that  Crecord  name>  shall  be  the  Crecord  name>  of  either  the  subject 
Crecord  type>  or  the  object  Crecord  type>;  the  contextual  Crecord  type>  of  the  Ccomponent  iden¬ 
tified  is  that  Crecord  type>. 
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f)  If  a  <component  identifier>  in  a  <component  identifier  match>  contains  a  <qualifier>  that  specifies 
OWNER  (MEMBER),  then  the  contextual  <record  type>  of  the  <component  identifier>  is  the 
object  (subject)  <record  type>. 

g)  If  a  <component  identifier>  in  a  <component  identifier  match>  does  not  contain  a  <qualifier>,  then 
the  <component  name>  of  that  <component  identifier>  shall  be  defined  in  either  the  subject  <record 
type>  or  the  object  <record  type>;  the  contextual  <record  type>  of  the  Ccomponent  identifier>  is 
that  <  record  type>. 

h)  The  data  items  referenced  by  <owner  component  identifier>s  shall  be  exactly  the  <component 
identifiers  listed  in  a  <record  uniqueness  clause>  in  the  object  <record  type>. 

i)  The  data  items  referenced  by  <member  component  identifiers  shall  be  data  items  of  the  subject 
<  record  type>.  The  <data  type>  of  the  <  component  type>  referenced  by  the  <  member  component 
identifier  of  a  <component  identifier  match>  shall  be  identical  to  the  <data  type>  of  the  <compo- 
nent  type>  referenced  by  the  <owner  component  identifier  of  that  <component  identifier  match>. 

General  Rules 

1)  If  STRUCTURAL  is  specified,  then  let  Ml,  M2,...  be  the  <component  identifiers  specified  as  <member 
component  identifiers.  The  contextual  <database  key>  of  those  <component  identifier>s  is  the  data¬ 
base  key>  of  the  new  member  record  occurrence.  Let  Ol,  02,...  be  the  <component  identifiers  speci¬ 
fied  as  <owner  component  identifiers.  The  contextual  database  key>  of  those  <component 
identifier  >s  is  the  <  database  key>  of  the  owner  record  occurrence  of  the  set  occurrence  specified  by  the 
<insert  operations  An  implicit  <member  check  clause>  of  the  following  form  is  enforced: 

CHECK  Ml  =  Ol  AND  M2  =  02  ... 
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6.17  <  retention  clause  > 

Function 

Define  the  retention  characteristics  of  a  member  <  record  type>  of  a  <set  type>. 

Format 

< retention  clause >  = 

RETENTION  {FIXED  |  MANDATORY  |  OPTIONAL} 
Syntax  Rules 
None. 

General  Rules 

None. 
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6.18  <  member  uniqueness  clause  > 

Function 

Specify  a  uniqueness  constraint  for  member  records  of  each  occurrence  of  a  <set  type>. 

Format 

< member  uniqueness  clause >  ::  = 

UNIQUE  <component  identified... 

Syntax  Rules 

1)  If  the  <component  name>  of  a  <component  identifier>  designates  an  array,  then  that  <component  iden¬ 
tified  shall  contain  <subscripts>. 

2)  A  given  <component  identified  shall  be  contained  at  most  once  in  a  single  Cmember  uniqueness  clause>. 

3)  The  subject  <  record  type>  of  a  <  member  uniqueness  clause  >  is  the  member  <  record  type>  of  the  con¬ 
taining  <  member  clause  >. 

The  contextual  <record  type>  of  each  <component  identified  in  a  <member  uniqueness  clause>  is  the 
subject  <record  type>. 

General  Rules 

1)  When  the  <component  identifieds  of  a  <member  uniqueness  clause>  are  referenced  for  a  record  occur¬ 
rence,  the  contextual  <  database  key>  for  those  <  component  identifier  >s  is  the  <  database  key>  of  that 
record  occurrence. 

2)  A  <member  uniqueness  clause>  is  violated  if  the  database  contains  an  occurrence  of  the  containing  <set 
type>  that  contains  two  member  occurrences  of  the  subject  <  record  type>  in  which  the  values  of  each  of 
the  components  designated  by  the  <component  identifieds  in  the  <member  uniqueness  clause>  in  the 
first  record  occurrence  are  equal  to  the  values  of  the  corresponding  components  in  the  second  record 
occurrence. 
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6.19  <key  clause> 

Function 

Define  the  sort  control  key  for  a  member  <record  type>  of  a  sorted  <set  type>. 

Format 

<  key  clause  >  ::  = 

KEY  <key  item>...  [<key  duplicates >] 


<key  item>  ::  = 

{ASCENDING  |  DESCENDING} 

{<component  identifier>  |  < record  type  key  item >}... 

Crecord  type  key  item>  ::=  RECORD  TYPE 


<  key  duplicates  >  : :  = 

DUPLICATES 

{  PROHIBITED 
|  FIRST 
|  LAST 
|  DEFAULT  } 


Syntax  Rules 

1)  If  the  <component  name>  of  a  <component  identifier>  designates  an  array,  then  that  <component  iden¬ 
tified  shall  contain  <  subscripts  >. 

2)  A  given  <component  identified  shall  be  contained  at  most  once  in  a  single  <key  clause>. 

3)  The  subject  <record  type>  of  a  <key  clause>  is  the  member  <record  type>  of  the  containing  <member 
clause  >. 

The  contextual  <record  type>  of  each  <component  identifier>  in  a  <key  clause>  is  the  subject  Crecord 
type>  of  the  <key  clause  >. 

4)  A  <key  clause>  shall  be  specified  if  the  containing  <set  type>  specifies  Csorted  order>;  otherwise,  a 
<key  clause>  shall  not  be  specified. 

5)  A  <key  duplicates>  shall  be  specified  if  the  containing  <set  type>  does  not  specify  a  Csorted  order> 
with  Corder  duphcates>;  otherwise,  a  Ckey  duphcates>  shall  not  be  specified. 

NOTE:  Together  with  rules  governing  the  Corder  clause>,  this  ensures  that  set  members  with  duplicate 
key  items  are  controlled  either  by  a  single  Corder  duplicates >  in  the  Corder  clause >  or  by  a  Ckey  dupli- 
cates>  in  each  Cmember  clause>. 

6)  A  single  Ckey  clause >  shall  contain  exactly  one  Crecord  type  key  item>  if  the  containing  Cset  type> 
specifies  a  Csorted  order>  with  Crecord  type  sequence>;  otherwise,  a  Ckey  clause>  shall  not  contain  a 
Crecord  type  key  item>. 
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7)  The  Ccomponent  identifiers  and  Crecord  type  key  item>  specified  in  a  <key  clause>  are  the  key  items 
that  constitute  the  sort  control  key  for  the  subject  <record  type>  as  a  member  <record  type>  of  the  con¬ 
taining  <set  type>.  If  a  key  item  is  immediately  preceded  by  ASCENDING  or  DESCENDING,  then  the 
direction  of  the  key  item  is  defined  to  be  respectively  ascending  or  descending.  If  a  key  item  K  is  imme¬ 
diately  preceded  by  another  key  item  K2,  then  the  direction  of  key  item  K  is  defined  to  be  the  direction  of 
key  item  K2. 

8)  If  no  <record  type  key  item>  is  specified  in  a  <key  clause>,  then  all  key  items  in  that  <key  clause>  are 
defined  to  be  common  key  items;  otherwise,  the  common  key  items  of  a  <key  clause>  are  defined  to  be 
the  <  record  type  key  item>  together  with  those  key  items  whose  ordinal  position  in  the  <key  clause  >  is 
less  than  the  ordinal  position  of  the  Crecord  type  key  item>.  Each  Cmember  clause>  of  a  <set  type> 
shall  contain  the  same  number  of  common  key  items.  All  common  key  items  that  are  at  the  same  ordinal 
position  in  the  <key  clause >  of  Cmember  clause >s  in  a  Cset  type>  shall  have  the  same  direction  and 
shall  either  be  Crecord  type  key  item>  or  shall  designate  Ccomponent  type>s  that  have  identical  Cdata 
type>s. 

General  Rules 

1)  When  the  Ccomponent  identifiers  of  a  Ckey  clause>  are  referenced  for  a  record  occurrence,  the  contex¬ 
tual  cdatabase  key>  for  those  Ccomponent  identifiers  is  the  Cdatabase  key>  of  that  record  occurrence. 

2)  The  key  items  are  stated  in  a  Ckey  clause >  in  order  of  decreasing  significance. 

3)  Depending  on  whether  the  direction  of  a  key  item  is  ascending  or  descending,  values  of  that  key  item  are 
ordered  respectively  from  the  lowest  to  the  highest  or  from  the  highest  to  the  lowest. 

4)  Case: 

a)  If  a  key  item  is  a  Ccomponent  identifier,  then  the  ordering  of  that  key  item  is  defined  by  either  the 
less  than  or  the  greater  than  relation  condition,  depending  on  whether  the  direction  of  the  key  item  is 
ascending  or  descending. 

b)  If  a  key  item  is  Crecord  type  key  item>,  then  the  ordering  of  that  key  item  is  defined  by  the  sequence 
of  Crecord  name>s  specified  in  the  Crecord  type  sequence >  of  the  C sorted  order >  of  the  containing 
Cset  type>. 

5)  The  Ckey  duplicates >  specifies  the  action  to  be  taken  when  the  execution  of  a  C store  statement >, 
Cmodify  statement>,  Cconnect  statement>,  or  Creconnect  statement>  would  cause  an  occurrence  of  the 
containing  Cset  type>  to  contain  two  or  more  member  records  that  have  equal  values  for  all  of  the  key 
items: 

Case: 

a)  If  PROHIBITED  is  specified,  then  the  Ckey  clause >  is  violated. 

b)  If  LAST  or  FIRST  is  specified,  then  member  records  that  have  equal  values  for  the  key  items  shall  be 
ordered  respectively  in  chronological  or  reverse  chronological  sequence.  This  chronology  is  based  on 
the  most  recent  time  at  which  a  C store  statement >,  Cmodify  statements  Cconnect  statements  or 
Creconnect  statement>  inserted  a  given  member  record  into  the  set  occurrence  or  a  Cmodify  state¬ 
ment  specified  values  for  one  or  more  key  items  in  the  given  member  record.  A  Cmodify  state¬ 
ment  >  that  specifies  values  for  one  or  more  key  items  in  a  member  record  that  are  equal  to  the  current 
values  for  those  key  items  in  that  record  establishes  a  new  point  in  the  chronology. 

c)  If  DEFAULT  is  specified,  then  member  records  that  have  equal  values  for  all  of  the  key  items  shall  be 
ordered  in  an  implementor-defined  sequence. 
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If  <key  duplicates  >  is  not  specified,  then  the  action  to  be  taken  is  controlled  by  the  <  order  duplicates  >  of 
the  containing  <set  type>. 
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6.20  < member  check  clause > 

Function 

Specify  a  validity  condition  on  member  records  of  each  occurrence  of  a  <set  type>. 

Format 

<  member  check  clause  >  ::  = 

CHECK  <condition> 

Syntax  Rules 

1)  The  subject  <  record  type>  of  a  <  member  check  clause  >  is  the  member  <  record  type>  of  the  containing 

<  member  clause  >. 

If  the  containing  <set  type>  of  a  <  member  check  clause  >  is  a  nonsingular  <set  type>,  then  the  object 

<  record  type>  of  the  <  member  check  clause  >  is  the  owner  <  record  type>  of  the  containing  <set  type>. 
If  the  containing  <set  type>  of  a  <member  check  clause>  is  a  singular  <set  type>,  then  the  <member 
check  clause  >  has  no  object  <  record  type>. 

2)  If  the  subject  <record  type>  and  the  object  <record  type>  are  the  same,  then  every  <component  identi¬ 
fied  in  the  <condition>  shall  contain  a  <qualifier>  that  specifies  either  OWNER  or  MEMBER. 

3)  Any  <component  identified  in  the  <condition>  that  contains  a  <component  name>  that  is  defined  in 
both  the  subject  <record  type>  and  the  object  <record  type>  (if  any)  of  the  <member  check  clause> 
shall  contain  a  <qualifier>. 

4)  Case: 

a)  If  a  <component  identifier>  in  the  <condition>  contains  a  <qualifier>  that  specifies  a  <record 
name>,  then  that  <  record  name>  shall  be  the  <  record  name>  of  either  the  subject  <  record  type>  or 
the  object  <record  type>  (if  any);  the  contextual  <record  type>  of  the  <component  identified  is 
that  <  record  type>. 

b)  If  a  Ccomponent  identifier>  in  the  <condition>  contains  a  <qualifier>  that  specifies  OWNER,  then 
the  Ccomponent  identified  shall  have  an  object  Crecord  type>,  and  the  contextual  Crecord  type>  of 
the  Ccomponent  identified  is  that  Crecord  type>. 

c)  If  a  Ccomponent  identified  in  the  Ccondition>  contains  a  Cqualified  that  specifies  MEMBER,  then 
the  contextual  Crecord  type>  of  the  Ccomponent  identified  is  the  subject  Crecord  type>. 

d)  If  a  Ccomponent  identified  in  the  Ccondition>  does  not  contain  a  Cqualified,  then  the  Ccompo¬ 
nent  name>  of  that  Ccomponent  identified  shall  be  defined  in  either  the  subject  Crecord  type>  or 
the  object  Crecord  type>  (if  any);  the  contextual  Crecord  type>  of  the  Ccomponent  identified  is 
that  Crecord  type>. 
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General  Rules 

1)  When  the  <condition>  of  a  <member  check  clause>  is  evaluated  for  a  set  occurrence,  the  contextual 
<database  key>  for  the  <component  identifier>s  in  that  <condition>  whose  contextual  <record  type>  is 
the  owner  <  record  type>  of  the  set  is  the  <  database  key>  of  the  owner  record  occurrence  of  that  set 
occurrence,  and  the  contextual  <database  key>  for  the  <  component  identifiers  in  that  <condition> 
whose  contextual  <  record  type>  is  the  member  <  record  type>  of  the  set  is  the  <  database  key>  of  the 
member  record  occurrence  of  that  set  occurrence. 

2)  A  <  member  check  clause  >  is  violated  if  the  database  contains  an  occurrence  of  the  containing  <set  type> 
in  which  the  <  condition  >  is  false  when  evaluated  in  respect  to  the  owner  record  occurrence  (if  any)  and 
any  occurrence  of  the  subject  <record  type>  that  is  a  member  of  that  set  occurrence. 
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6.21  <  component  identifier > 

Function 

Reference  a  component  or  data  item. 

Format 

<  component  identifier >  ::  = 

<dot  style  component  identifier> 

|  <of  style  component  identifier> 

<dot  style  component  identifier>  ::  = 

[<qualifier>.]  <component  name>  [< subscripts >] 

<of  style  component  identifier >  ::  = 

<component  name>  [< subscripts >]  [OF  <qualifier>] 


<qualifier>  ::  = 

<  record  name> 

|  OWNER 
|  MEMBER 

Syntax  Rules 

1)  The  contextual  <record  type>  of  a  <component  identifier>  is  specified  in  the  Syntax  Rules  of  the  pro¬ 
duction  symbol  that  immediately  contains  the  <  subscripts  >. 

2)  If  the  <component  identifier>  contains  a  <qualifier>,  then: 

a)  If  the  <  qualifier  >  contains  a  <  record  name>,  then  that  <  record  name>  shall  designate  the  contextual 

<  record  type>. 

b)  If  the  <qualifier>  specifies  OWNER,  then  the  <component  identifier>  shall  be  contained  in  a  <set 
type>,  and  the  owner  <  record  type>  of  that  <set  type>  shall  be  the  contextual  <  record  type>. 

c)  If  the  <qualifier>  specifies  MEMBER,  then  the  Ccomponent  identifier>  shall  be  contained  in  a 

<  member  clause  >,  and  the  member  <  record  name>  of  that  <  member  clause  >  shall  designate  the 
contextual  <  record  type>. 

3)  The  <  component  name>  shall  designate  a  <  component  type>  of  the  contextual  <  record  type>.  That 
<  component  type>  is  the  subject  <  component  type>. 

4)  If  a  <component  identifier>  contains  <subscripts>,  then: 

a)  The  subject  Ccomponent  type>  shall  define  an  array. 

b)  The  contextual  <  occurs  clause  >  of  the  <  subscripts  >  is  the  <  occurs  clause  >  contained  in  the  subject 
Ccomponent  type>. 

c)  Each  Coperand>  in  the  Csubscripts>  shall  be  a  Cliteral>. 
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General  Rules 

1)  The  contextual  <database  key>  of  a  <component  identifier>  is  specified  in  the  General  Rules  of  the  pro¬ 
duction  symbol  that  immediately  contains  the  <component  identifier^ 

2)  A  <component  identifier>  references  a  data  item  or  array  in  the  record  referenced  by  the  contextual 
<database  key>,  as  follows: 

Case: 

a)  If  the  subject  <component  type>  of  a  <component  identifier>  defines  a  data  item,  then  the  Compo¬ 
nent  identifier>  references  that  data  item. 

b)  If  the  subject  Component  type>  of  a  Component  identifier>  defines  an  array  and  the  Component 
identifier>  does  not  contain  <subscripts>,  then  the  Component  identifier>  references  that  array. 

c)  If  the  subject  Component  type>  of  a  Component  identifier>  defines  an  array  and  the  Component 
identifier>  contains  <subscripts>,  then  the  < component  identifier>  references  the  i-th  data  item  in 
the  array,  where  i  is  the  value  of  the  <  subscripts  >. 


6.  Schema  definition  language 


57 


AMERICAN  NATIONAL  STANDARD  X3. 133-1986 


7.  Subschema  definition  language 
7.1  <  subschema  > 

Function 

Define  a  user  view  of  the  database. 

Format 

< subschema >  ::  = 

<  subschema  name  clause  > 

[  {<record  view>  |  <set  view>}...] 

Syntax  Rules 

None. 

General  Rules 

None. 
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7.2  <  subschema  name  clause  > 

Function 

Name  a  <  subschema  >. 

Format 

< subschema  name  clause >  ::  = 

<dot  style  subschema  name  clause  > 

|  <of  style  subschema  name  clause  > 

<dot  style  subschema  name  clause >  ::  = 

SUBSCHEMA  <schema  name >.< subschema  name> 

<of  style  subschema  name  clause  >  ::  = 

SUBSCHEMA  < subschema  name>  OF  < schema  name> 

< subschema  name>  ::=  < identifier > 

Syntax  Rules 

1)  The  <  schema  name>  shall  designate  a  <  schema  >  in  the  same  environment  as  the  <  subschema  >.  That 
<schema>  is  the  subject  <schema>  of  the  <subschema>.  The  concept  of  environment  is  implementor- 
defined. 

2)  The  <subschema  name>  of  a  <subschema>  shall  be  different  from  the  <subschema  name>  of  any  other 
<  subschema  >  that  has  the  same  subject  <  schema  >. 

General  Rules 

1)  A  <subschema  name  clause>  defines  the  <identifier>  to  be  a  <subschema  name>  that  designates  the 
containing  <subschema>  within  the  subject  <schema>. 
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7.3  <  record  view> 

Function 

Specify  that  a  <  record  type>  is  to  be  included  in  a  <  subschema  >,  and  declare  an  <  identifier  >  that  shall  des¬ 
ignate  it  within  the  <  subschema  >. 

Format 

< record  vie w>  ::  = 

RECORD  [Crecord  renamed>]  <record  view  name> 

[<  component  list>] 

< record  renamed >  ::  = 

<  record  name>  RENAMED 

< record  view  name>  = 

<identifier> 

< component  list>  ::  = 

< component  view>...  |  ALL 

Syntax  Rules 

1)  Case: 

a)  If  a  <record  renamed>  is  specified,  then  the  <record  name>  shall  designate  a  Crecord  type>  in  the 
subject  <schema>.  That  Crecord  type>  is  the  subject  Crecord  type>. 

b)  If  a  Crecord  renamed>  is  omitted,  then  the  Crecord  view  name>  shall  be  a  Crecord  name>  that  des¬ 
ignates  a  Crecord  type>  in  the  subject  Cschema>.  That  Crecord  type>  is  the  subject  Crecord 
type>. 

2)  The  Crecord  view  name>  shall  be  different  from  the  Crecord  view  name>  of  every  other  Crecord  view> 
in  the  containing  Csubschema>.  The  subject  Crecord  type>  shall  be  different  from  the  subject  Crecord 
type>  of  every  other  Crecord  view>  in  the  containing  C subschema >. 

3)  If  a  Ccomponent  list>  of  ALL  is  specified,  then  it  is  equivalent  to  a  Ccomponent  list>  that  contains  a 
Ccomponent  view>  for  every  Ccomponent  type>  in  the  subject  Crecord  type>,  where  the  Ccomponent 
view>  corresponding  to  a  Ccomponent  type>  contains  a  Ccomponent  view  name>  that  is  the  Ccompo¬ 
nent  name>  of  the  Ccomponent  type>,  and  contains  no  Ccomponent  renamed>. 

General  Rules 

1)  A  Crecord  view>  defines  the  Cidentifier>  to  be  a  Crecord  view  name>  that  designates  the  subject 
Crecord  type>. 
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7.4  < component  view> 

Function 

Specify  that  a  <component  type>  is  to  be  included  within  a  <subschema>,  and  declare  an  <identifier>  that 
shall  designate  it  within  the  <  subschema  >. 

Format 

< component  view>  = 

ITEM  [Ccomponent  renamed>]  < component  view  name> 

< component  renamed >  ::  = 

<  component  name>  RENAMED 

<  component  view  name>  ::  = 

<  identifier  > 

Syntax  Rules 

1)  The  subject  <record  type>  is  the  <record  type>  designated  by  the  <record  view  name>  of  the  containing 
<record  view>. 

2)  Case: 

a)  If  a  <component  renamed>  is  specified,  then  the  <component  name>  shall  designate  a  < component 
type>  contained  in  the  subject  <  record  type>.  That  <  component  type>  is  the  subject  <  component 
type>. 

b)  If  a  < component  renamed >  is  omitted,  then  the  < component  view  name>  shall  be  a  < component 
name>  that  designates  a  <  component  type>  contained  in  the  subject  <  record  type>.  That  <  compo¬ 
nent  type>  is  the  subject  <  component  type>. 

3)  The  <  component  view  name>  shall  be  different  from  the  <  component  view  name>  of  every  other  <  com¬ 
ponent  view>  in  the  containing  Crecord  view>.  The  subject  <component  type>  shall  be  different  from 
the  subject  <component  type>  of  every  other  <component  view>  in  the  containing  Crecord  view>. 

General  Rules 

1)  A  Ccomponent  view>  defines  the  <identifier>  to  be  a  < component  view  name>  that  designates  the 
subject  Ccomponent  type>. 
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7.5  <setview> 

Function 

Specify  that  a  <set  type>  is  to  be  included  in  a  <subschema>,  and  declare  an  <identifier>  that  shall  desig¬ 
nate  it  within  the  <  subschema  >. 

Format 

<set  view>  = 

SET  [<set  renamed  >]  <set  view  name> 

<set  renamed>  = 

<set  name>  RENAMED 

<set  view  name>  = 

<identifier> 

Syntax  Rules 

1)  Case: 

a)  If  a  <set  renamed>  is  specified,  then  the  <set  name>  shall  designate  a  <set  type>  in  the  subject 
<  schema  >.  That  <set  type>  is  the  subject  <set  type>. 

b)  Ifa  <set  renamed>  is  omitted,  then  the  <set  view  name>  shall  be  a  <set  name>  that  designates  a 
<set  type>  in  the  subject  <  schema  >.  That  <set  type>  is  the  subject  <set  type>. 

2)  The  <set  view  name>  shall  be  different  from  the  <set  view  name>  of  every  other  <set  view>  in  the 
containing  <subschema>.  The  subject  <set  type>  shall  be  different  from  the  subject  <set  type>  of  every 
other  <set  view>  in  the  containing  <  subschema  >. 

3)  The  owner  <  record  type>  and  at  least  one  member  <record  type>  of  the  subject  <set  type>  shall  be 
designated  by  a  <  record  view>  of  the  containing  <  subschema  >. 

General  Rules 

1)  A  <set  view>  defines  the  <identifier>  to  be  a  <set  view  name>  that  designates  the  subject  <set  type>. 
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8.  Module  language 


8.1  <module> 

Function 

Define  a  module. 

Format 

<module>  ::  = 

<  module  name  clause  > 

<  language  clause  > 

<  subschema  specification  > 

[<  temporary  set  specifications  >] 

<procedure>... 

< language  clause >  ::  = 

LANGUAGE  {COBOL  |  FORTRAN  |  PASCAL  |  PLI} 

<  subschema  specification  >  ::  = 

<dot  style  subschema  specification> 

|  <of  style  subschema  specification  > 

<dot  style  subschema  specification >  ::  = 

SUBSCHEMA  < schema  name >.< subschema  name> 

<of  style  subschema  specification >  ::  = 

SUBSCHEMA  <subschema  name>  OF  <schema  name> 

Syntax  Rules 

1)  The  <  schema  name>  shall  designate  a  <  schema  >  in  the  same  environment  as  the  <  module  >.  That 
<  schema  >  is  the  subject  <  schema  >  of  the  <  module  >.  The  concept  of  environment  is  implementor- 
defined. 

2)  The  <subschema  name>  shall  designate  a  <subschema>  in  the  same  environment  as  the  <module>.  The 
subject  <schema>  of  that  <subschema>  shall  be  the  subject  <schema>  of  the  <module>.  That 
<subschema>  is  the  subject  <subschema>  of  the  <module>. 

General  Rules 

1)  A  <module>  shall  be  associated  with  an  application  program  during  its  execution.  An  application  program 
shall  be  associated  with  at  most  one  <module>. 

2)  If  the  <language  clause>  of  a  <module>  specifies  COBOL  (respectively  FORTRAN,  PASCAL,  PLI)  and 
if  the  agent  that  performs  a  call  of  a  <procedure>  in  that  <module>  is  not  a  standard  COBOL  program 
(respectively  standard  FORTRAN,  Pascal,  PL/I  program),  then  the  results  are  undefined. 
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3)  Before  the  first  time  that  a  programming  language  agent  performs  a  call  of  a  <procedure>  in  a  <module>, 
construct  an  initial  <  session  state  >,  and  associate  that  <  session  state  >  with  every  call  by  that  program¬ 
ming  language  agent  of  any  <  procedure  >  in  the  <  module  >. 

4)  After  the  last  time  that  a  programming  language  agent  performs  a  call  of  a  <procedure>  in  a  <module>, 
perform  a  <  rollback  statement  >  specifying  FINISH,  and  destroy  the  <  session  state  >  associated  with  the 
<  module  >. 
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8.2  < module  name  clause > 

Function 

Name  a  <module>. 

Format 

< module  name  clause >  ::  = 

MODULE  [<  module  name>] 

< module  name>  ::=  < identifier > 

Syntax  Rules 

1)  The  Cmodule  name>  shall  be  different  from  the  <module  name>  of  any  other  <module>  in  the  same 
environment.  The  concept  of  environment  is  implementor-defined. 

General  Rules 

1)  A  <module  name  clause>  defines  the  optional  <identifier>  to  be  a  <module  name>  that  designates  the 
containing  Cmodule >  within  the  environment. 
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8.3  < temporary  set  specifications > 

Function 

Specify  temporary  sets. 

Format 

<  temporary  set  specifications  >  ::  = 

<temporary  set  specification^.. 

< temporary  set  specification >  ::  = 

SET  <set  view  name> 

Syntax  Rules 

1)  The  <set  view  name>  of  each  <temporary  set  specification >  shall  be  different  from  the  <set  view  name> 
of  any  other  <temporary  set  specification >  in  the  containing  <module>,  and  shall  be  different  from  the 
<set  view  name>  of  any  <set  view>  in  the  subject  <  subschema  >. 

2)  A  <temporary  set  specification >  with  a  <set  view  name>  S  defines  a  temporary  <set  type>  with  an 
implicit  <set  name  clause >,  < owner  clause >,  and  < order  clause >  as  follows: 

SET  S  OWNER  SYSTEM  ORDER  LAST 

and,  for  each  <record  view  name>  R  specified  in  the  subject  <subschema>,  a  <member  clause>  with  a 
<member  record  name  clause>,  an  <insertion  clause>,  and  a  <retention  clause>  as  follows: 

MEMBER  R  INSERTION  MANUAL  RETENTION  OPTIONAL 

General  Rules 

1)  The  <set  view  name>  of  a  <  temporary  set  specification  >  designates  the  temporary  <set  type>  defined 
by  the  <  temporary  set  specification  >. 
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8.4  < procedure > 

Function 

Define  a  procedure. 

Format 

< procedure >  ::  = 

PROCEDURE  <procedure  name>  [<parameter  declaration^*...] 
[<NDL  statement >...] 

< parameter  declaration >  ::  = 

<parameter  name>  <data  type>  [<occurs  clause>] 

|  RECORD 
|  STATUS 
|  TEST 

<procedure  name>  ::=  <identifier> 

< parameter  name >  ::=  <identifier> 

<NDL  statement>  ::  = 

<  commit  statement  > 

|  <  connect  statement  > 

|  <  disconnect  statement  > 

|  <  erase  statement  > 

|  <find  statement> 

|  <get  statement> 

|  <  modify  statement  > 

|  <  nullify  cursor  statement  > 

|  <ready  statement> 

|  <reconnect  statement> 

|  <  rollback  statement  > 

|  <  store  statement  > 

|  <test  statement  > 

< test  statement >  ::  = 

<test  database  key  equal  statement  > 

|  <test  database  key  null  statement> 

|  <test  set  empty  statement  > 

|  <test  set  membership  statement > 
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Syntax  Rules 

1)  The  <  procedure  name>  shall  be  different  from  the  <  procedure  name>  of  any  other  <  procedure  >  in  the 
containing  <  module  >. 

2)  The  <parameter  name>  of  each  <parameter  declaration>  in  a  <procedure>  shall  be  different  from  the 
<parameter  name>  of  any  other  <parameter  declaration>  in  that  <procedure>. 

3)  Any  <parameter  name>  contained  in  an  <NDL  statement>  in  a  <procedure>  shall  be  specified  in  a 

<  parameter  declaration  >  in  that  <  procedure  >. 

4)  If  a  <component  view  name>  in  a  <component  view  identifier>  in  an  <NDL  statement>  is  identical  to  a 
<parameter  name>  specified  in  the  containing  <procedure>,  then  the  <component  view  identifier>  shall 
contain  a  <  record  view  name>. 

5)  The  <record  type>  designated  by  each  <record  view  name>  in  each  <NDL  statement>  shall  be  defined 
in  the  subject  <subschema>. 

6)  The  <set  type>  designated  by  each  <set  view  name>  in  each  <NDL  statement>  shall  be  defined  in  the 
subject  <subschema>  or  in  the  <temporary  set  specifications>  of  the  containing  <module>. 

7)  A  <procedure>  shall  include  at  most  one  RECORD  <parameter  declaration>,  at  most  one  STATUS 
< parameter  declaration >,  and  at  most  one  TEST  < parameter  declarations 

8)  A  <procedure>  shall  contain  at  most  one  <test  statements 

9)  If  a  <  procedure  >  contains  a  <test  statement  >,  then  the  <procedure>  shall  contain  a  TEST  <  parameter 
declarations  If  a  < procedure >  does  not  contain  a  <test  statement >,  then  it  shall  not  contain  a  TEST 

<  parameter  declaration  >. 

10)  A  <procedure>  shall  contain  at  most  one  <NDL  statement>  that  is  a  <commit  statement>  or  a 
<rollback  statements  If  a  <procedure>  contains  such  an  <NDL  statements  then  it  shall  be  the  last 
<NDL  statement>  in  the  <procedure>. 

11)  A  valid  call  of  a  < procedure >  shall  supply  n  parameters,  where  n  is  the  number  of  < parameter 
declaration  >s  in  that  <  procedure  >. 

12)  Case: 

a)  If  the  i-th  <parameter  declaration>  contains  an  <occurs  clauses  then  the  i-th  parameter  shall  be  an 
array  with  the  same  number  of  data  item  occurrences. 

b)  If  the  i-th  <parameter  declaration>  is  the  RECORD  <parameter  declarations  then  the  type  of  the 
i-th  parameter  shall  define  a  single  occurrence  of  a  character  string  of  length  18. 

c)  If  the  i-th  <parameter  declaration>  is  the  STATUS  <parameter  declarations  then  the  type  of  the  i-th 
parameter  shall  define  a  single  occurrence  of  a  character  string  of  length  5. 

d)  If  the  i-th  <parameter  declaration>  is  the  TEST  <parameter  declarations  then  the  type  of  the  i-th 
parameter  shall  define  a  single  occurrence  of  a  character  string  of  length  1 . 

13)  If  the  i-th  <parameter  declaration>  of  a  <procedure>  is  respectively  the  RECORD,  STATUS,  or  TEST 
<parameter  declarations  then  the  i-th  parameter  that  is  supplied  in  a  call  of  that  <procedure>  is  referred 
to  as  the  RECORD  parameter,  the  STATUS  parameter,  or  the  TEST  parameter. 
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14)  The  subject  <language  clause>  of  a  <procedure>  is  the  Clanguage  clause>  of  the  containing  <module>. 

15)  Case: 

a)  If  the  subject  <language  clause>  specifies  COBOL,  then: 

i)  Any  <data  type>  in  a  <parameter  declaration>  shall  specify  either  CHARACTER  or 
NUMERIC. 

ii)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  CHARACTER  L  for  some 
<length>  L,  then  the  type  of  the  i-th  parameter  shall  be  COBOL  alphanumeric  with  a  length  of  L. 

iii)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  NUMERIC  P  S  for  some 
<precision>  and  <scale>  P  and  S,  then  the  type  of  the  i-th  parameter  shall  be  COBOL  usage 
DISPLAY  sign  LEADING  SEPARATE  and  the  following  PICTURE: 

iv)  Case: 

1.  If  S>P,  then  a  PICTURE  with  an  "S"  followed  by  a  "V"  followed  by  S-P  "P"s  followed  by  P 
"9"s. 

2.  If  S=P,  then  a  PICTURE  with  an  "S"  followed  by  a  "V"  followed  by  P  "9"s. 

3.  If  P>S>0,  then  a  PICTURE  with  an  "S"  followed  by  P-S  "9"s  followed  by  a  "V"  followed 
by  S  "9"s. 

4.  If  S=0,  then  a  PICTURE  with  an  "S"  followed  by  P  "9"s  followed  by  a  "V". 

5.  If  S<0,  then  a  PICTURE  with  an  "S"  followed  by  P  "9"s  followed  by  abs(S)  "P"s. 

b)  If  the  subject  <language  clause>  specifies  FORTRAN,  then: 

i)  Any  <data  type>  in  a  <  parameter  declaration  >  shall  specify  either  CHARACTER,  INTEGER, 
REAL,  or  DOUBLE  PRECISION. 

ii)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  CHARACTER  L  for  some 
<length>  L,  then  the  type  of  the  i-th  parameter  shall  be  FORTRAN  CHARACTER  with  a  length 
of  L. 

iii)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  INTEGER,  REAL,  or 
DOUBLE  PRECISION,  then  the  type  of  the  i-th  parameter  shall  be  respectively  FORTRAN 
INTEGER,  REAL,  or  DOUBLE  PRECISION. 

c)  If  the  subject  Clanguage  clause>  specifies  PASCAL,  then: 

i)  Any  <data  type>  in  a  Cparameter  declaration>  shall  specify  either  CHARACTER,  INTEGER, 
or  REAL. 

ii)  If  the  i-th  Cparameter  declaration>  specifies  a  Cdata  type>  that  is  CHARACTER  L  for  some 
C  length  >  L,  then  the  type  of  the  i-th  parameter  shall  be  Pascal  string  with  a  length  of  L. 

iii)  If  the  i-th  Cparameter  declaration>  specifies  a  cdata  type>  that  is  INTEGER  or  REAL,  then  the 
type  of  the  i-th  parameter  shall  be  respectively  Pascal  INTEGER  or  REAL. 

d)  If  the  subject  Clanguage  clause >  specifies  PLI,  then: 
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i)  Any  <data  type>  in  a  <parameter  declaration>  shall  specify  either  CHARACTER,  FIXED,  or 
FLOAT. 

ii)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  CHARACTER  L  for  some 
<  length  >  L,  then  the  type  of  the  i-th  parameter  shall  be  PL/I  CHARACTER  with  a  length  of  L. 

iii)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  FIXED  P  S  for  some  <preci- 
sion>  and  <scale>  P  and  S,  then  the  type  of  the  i-th  parameter  shall  be  PL/I  FIXED  REAL 
DECIMAL  (P,S). 

iv)  If  the  i-th  <parameter  declaration>  specifies  a  <data  type>  that  is  FLOAT  P  for  some  <preci- 
sion>  P,  then  the  type  of  the  i-th  parameter  shall  be  PL/I  FLOAT  REAL  BINARY  (P). 

General  Rules 

1)  A  <  procedure  >  defines  a  procedure  that  may  be  called  by  an  implementor-defined  agent. 

2)  When  a  <procedure>  is  called  by  a  programming  language  agent: 

a)  If  no  transaction  is  active  for  that  agent,  then  initiate  a  transaction  and  associate  that  transaction  with 
this  call  and  with  subsequent  calls  by  that  agent  of  any  <procedure>  in  the  containing  <module> 
until  the  agent  terminates  that  transaction. 

b)  If  the  <procedure>  contains  a  list  of  one  or  more  <NDL  statements,  then  perform  each  <NDL 
statement  in  that  list,  from  left  to  right,  as  specified  in  the  General  Rules  of  each  <NDL  statement. 

3)  The  <  parameter  name>  of  a  <  parameter  declaration  >  in  a  <  procedure  >  designates  that  <  parameter  dec¬ 
laration  >  in  the  <  procedure  >. 

4)  If  execution  of  any  <NDL  statement  in  the  <procedure>  cannot  be  completed  because  of  a  deadlock, 
then  raise  exception  procedure:  deadlock. 

5)  Case: 

a)  If  no  exception  is  raised  during  the  execution  of  any  <NDL  statement  in  the  <procedure>,  then: 
Case: 

i)  If  the  <procedure>  contains  a  STATUS  <parameter  declarations  then  set  the  value  of  the 
STATUS  parameter  to  the  value  specified  for  procedure:  success  in  clause  12,  “Status  codes”  on 
page  117. 

ii)  If  the  <procedure>  contains  a  RECORD  <parameter  declarations  then: 

Case: 

1.  If  the  <database  key>  of  the  <session  cursor>  is  not  null,  then  set  the  value  of  the  RECORD 
parameter  to  the  <  record  view  name>  that  designates  the  <  record  type>  of  the  record  refer¬ 
enced  by  that  <database  keys 

2.  If  the  <database  key>  of  the  <session  cursor>  is  null,  then  set  the  value  of  the  RECORD 
parameter  to  all  space  characters. 

b)  If  an  exception  is  raised  during  the  execution  of  any  <NDL  statement>  in  the  <procedure>,  then: 
i)  Cancel  all  changes  made  to  the  database  by  the  execution  of  the  <procedure>. 
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ii)  Cancel  all  changes  made  to  the  <session  state>  by  the  execution  of  the  <procedure>. 

iii)  If  the  <procedure>  contains  a  STATUS  <parameter  declaration>,  then  set  the  value  of  the 
STATUS  parameter  to  the  value  specified  for  the  exception  in  clause  12,  “Status  codes”  on 
page  117. 

iv)  If  the  <procedure>  contains  a  TEST  <parameter  declaration^*,  then  set  the  value  of  the  TEST 
parameter  to  "0". 
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9.  Data  manipulation  language 
9.1  <  commit  statement  > 

Function 

Terminate  the  current  transaction  with  commit. 

Format 

< commit  statement >  = 

COMMIT  [FINISH] 

Syntax  Rules 

None. 

General  Rules 

1)  Terminate  the  current  transaction. 

2)  Make  all  database  changes  made  by  the  current  transaction  accessible  to  concurrent  sessions. 

3)  For  each  <temporary  set>  in  the  <temporary  sets>,  remove  each  member  record  from  membership  in 
that  set. 

4)  Set  the  <cursors>  to  the  initial  <cursors>  for  the  subject  <subschema>. 

5)  If  FINISH  is  specified,  then  set  the  <ready  list>  to  empty. 
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9.2  < connect  statement > 

Function 

Establish  the  membership  of  a  record  occurrence  in  a  set. 

Format 

< connect  statement >  ::  = 

CONNECT  <database  key  identifier>  TO  <set  view  name> 

Syntax  Rules 

1)  An  eligible  <  record  type>  is  a  Crecord  type>  that  is  defined  as  a  member  <  record  type>  of  the  <set 
type>  designated  by  the  <set  view  name>,  and  that  has  an  <insertion  clause>  specifying  MANUAL  or  a 
<retention  clause>  specifying  OPTIONAL  in  that  <set  type>. 

2)  If  the  <database  key  identifier>  specifies  a  Crecord  view  name>,  then  that  Crecord  view  name>  shall 
designate  an  eligible  Crecord  type>. 

General  Rules 

1)  The  object  cdatabase  key>  is  the  Cdatabase  key>  referenced  by  the  Cdatabase  key  identifier>.  If  that 
Cdatabase  key>  is  null,  then  raise  exception  connect:  database  key  is  null. 

The  object  Crecord  type>  is  the  Crecord  type>  referenced  by  the  object  Cdatabase  key>. 

2)  If  the  Crecord  view  name>  of  the  object  Crecord  type>  does  not  designate  a  Cready  specification>  in  the 
Cready  list>  having  an  Caccess  intent>  of  UPDATE,  then  raise  exception  connect:  record  not  ready  for 
update. 

3)  If  the  object  Crecord  type>  is  not  an  eligible  Crecord  type>,  then  raise  exception  connect:  ineligible  record 
type. 

4)  Perform  the  Cinsert  operation>  with  the  object  cdatabase  key>  as  the  Cinsert  record>,  the  Cset  view 
name>  of  the  Cconnect  statement>  as  the  Cinsert  set  type>,  the  Cdatabase  key>  of  the  Cowner>  of  the 
Cset  cursor>  designated  by  the  Cset  view  name>  of  the  Cconnect  statement>  as  the  Cinsert  set  owner>, 
and  update  as  the  Cinsert  cursor  disposition >. 
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9  9.3  <  disconnect  statement  > 

Function 

Remove  a  record  from  set  membership  in  a  specified  <set  type>. 

Format 

<disconnect  statement>  ::  = 

DISCONNECT  <database  key  identifier>  FROM  <set  view  name> 

Syntax  Rules 

1)  An  eligible  <record  type>  is  a  <record  type>  that  is  defined  as  a  member  <record  type>  of  the  <set 
type>  designated  by  the  <set  view  name>,  and  that  has  a  <  retention  clause  >  in  that  <set  type>  speci¬ 
fying  OPTIONAL. 

2)  If  the  <database  key  identifier>  specifies  a  <record  view  name>,  then  that  <record  view  name>  shall 
designate  an  ehgible  <  record  type>. 

General  Rules 

1)  The  object  <database  key>  is  the  <database  key>  referenced  by  the  <database  key  identifier>.  If  that 
<database  key>  is  null ,  then  raise  exception  disconnect:  database  key  is  null. 

^  The  object  <record  type>  is  the  <record  type>  referenced  by  the  object  <database  key>. 

2)  If  the  <record  view  name>  of  the  object  <record  type>  does  not  designate  a  <ready  specification >  in  the 
<ready  list>  having  an  <access  intent>  of  UPDATE,  then  raise  exception  disconnect:  record  not  ready  for 
update. 

3)  If  the  object  <  record  type>  is  not  an  ehgible  <  record  type>,  then  raise  exception  disconnect:  ineligible 
record  type. 

4)  Perform  the  <remove  operation>  with  the  object  <database  key>  as  the  <remove  record>  and  the  <set 
view  name>  of  the  <  disconnect  statement  >  as  the  <  remove  set  type>. 
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9.4  < erase  statement > 

Function 

Remove  one  or  more  records  from  the  database. 

Format 

< erase  statement >  ::  = 

ERASE  <database  key  identifier>  WITH  <cascade  specification > 

Ccascade  specification>  ::  = 

FULL  CASCADE  |  PARTIAL  CASCADE 

Syntax  Rules 

None. 

General  Rules 

1)  The  object  <database  key>  is  the  <database  key>  referenced  by  the  <database  key  identifiers  If  that 
<database  key>  is  null,  then  raise  exception  erase:  database  key  is  null. 

The  object  record  is  the  record  referenced  by  the  object  <database  key>.  The  object  <record  type>  is 
the  <  record  type>  of  the  object  record. 

2)  If  the  <  record  view  name>  of  the  object  <  record  type>  does  not  designate  a  <  ready  specification  >  in  the 
<ready  list>  having  an  <  access  intent  >  of  UPDATE,  then  raise  exception  erase:  record  not  ready  for 
update. 

3)  For  each  <set  type>  of  which  the  object  record  is  currently  a  member,  perform  the  <remove  operation> 
with  the  object  <database  key>  as  the  <remove  record>  and  the  <set  name>  of  the  <set  type>  as  the 
<  remove  set  type>. 

4)  The  affected  sets  are  those  whose  owner  record  is  the  object  record.  The  affected  records  are  those  that 
are  members  of  one  or  more  affected  sets. 

5)  Case: 

a)  If  the  <cascade  specification >  specifies  FULL  CASCADE,  then  erase  all  affected  records. 

b)  If  the  Ccascade  specification>  specifies  PARTIAL  CASCADE,  then: 

i)  If  any  affected  set  contains  any  mandatory  member,  then  raise  exception  erase:  set  has  mandatory 
member. 

ii)  Erase  any  affected  record  that  is  a  fixed  member  of  any  affected  set. 

iii)  For  each  affected  record  that  is  an  optional  member  of  any  affected  set,  perform  the  Cremove 
operation>  with  the  cdatabase  key>  of  the  affected  record  as  the  Cremove  record>  and  the  Cset 
name>  of  the  Cset  type>  of  the  affected  set  as  the  Cremove  set  type>. 
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6)  Erase  the  object  record.  The  relative  order  of  other  record  occurrences  under  implementor-defined 
ordering  criteria  remains  unchanged. 

7)  If  the  <database  key>  of  the  <session  cursor>  is  equal  to  the  <database  key>  of  the  object  record,  then 
set  the  <  session  cursor >  to  null. 

If  the  <database  key>  of  any  <record  cursor>  is  equal  to  the  <database  key>  of  the  object  record,  then 
set  the  <database  key>  of  that  <record  cursor>  to  null. 

If  the  <database  key>  of  the  object  record  is  equal  to  the  <owner>  in  any  <set  cursor>,  then  set  both 
the  <owner>  and  the  <position>  of  that  <set  cursor>  to  null. 

8)  Apply  General  Rules  3  through  8  of  the  < erase  statement>  to  each  erased  record  as  if  it  were  the  object 
record. 
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9.5  <find  statement> 

Function 

Select  a  record  in  the  database. 

Format 

<find  statement >  ::  = 

FIND 

<find  specification  > 

[<find  intent>] 

[<find  cursor  disposition  >] 

<find  specification >  = 

<database  key  identifier> 

|  <  search  specification  > 

< search  specification >  ::  = 

<  search  orientation  > 

<  domain  specification  > 

[WHERE  <  condition  >] 

< search  orientation >  = 

FIRST  |  LAST  |  NEXT  |  PRIOR 
|  [ABSOLUTE  |  RELATIVE}  <signed  integer> 

< domain  specification >  ::  = 

<  record  type  domain  > 

|  <set  domain  > 

|  <  subschema  domain  > 

Crecord  type  domain  >  ::  = 

<  record  view  name> 

< set  domain >  ::  = 

[<  record  view  name>]  IN  <set  view  name> 

<  subschema  domain  >  ::  = 

SUBSCHEMA  RECORD 

<find  intent >  ::  = 

FOR  [RETRIEVE  |  UPDATE} 

<find  cursor  disposition>  ::  = 

RETAIN  ALL 
|  <find  specific  disposition  > 

<find  specific  disposition>  ::  = 

[<position  member>] 

[<find  specific  retention>] 
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<position  member>  ::  = 

AS  MEMBER  <set  view  name>... 

<find  specific  retention >  ::  = 

RETAIN  RECORD 
|  RETAIN  SET  <set  view  name>... 

|  RETAIN  RECORD  SET  <set  view  name>... 

Syntax  Rules 

1)  If  the  <find  specification >  is  a  < search  specification >,  then: 

a)  If  the  <search  orientation>  contains  a  <signed  integer>,  then  the  value  of  that  <signed  integer> 
shall  not  be  0. 

b)  Case: 

i)  If  the  <  domain  specification  >  is  a  <record  type  domain  >,  then  the  object  <  record  type>  of  the 
<  search  specification  >  is  the  <  record  type>  designated  by  the  <  record  view  name>  contained  in 
the  <domain  specification^*. 

ii)  If  the  <domain  specification>  is  a  <set  domain>,  then: 

1.  The  object  <set  type>  of  the  <domain  specification>  is  the  <set  type>  designated  by  the 
<set  view  name>. 

2.  If  the  <search  specification>  includes  a  WHERE  <condition>  and  the  object  <set  type> 
contains  multiple  member  <record  type>s,  then  the  <set  domain>  shall  specify  a  <record 
view  name>. 

If  the  <set  domain>  specifies  a  <record  view  name>,  then  the  <record  type>  designated  by 
<  record  view  name>  shall  be  a  member  <  record  type>  of  the  object  <set  type>.  That 
Crecord  type>  is  the  object  <record  type>  of  the  <search  specification^ 

If  the  <set  domain  >  does  not  specify  a  <  record  view  name>,  then  the  object  <  record  type>s 
of  the  <search  specification >  are  all  subschema  Crecord  type>s  that  are  member  Crecord 
type>s  of  the  object  Cset  type>. 

iii)  If  the  Cdomain  specification >  is  a  Csubschema  domain>,  then: 

1.  The  object  Crecord  type>s  of  the  C search  specification >  are  the  Crecord  type>s  specified 
by  the  Crecord  view>s  of  the  subject  C subschema >. 

2.  If  the  Csearch  specification>  includes  a  WHERE  Ccondition>,  then  the  subject 
C subschema >  shall  contain  exactly  one  Crecord  view>. 

c)  If  the  Csearch  specification >  contains  a  WHERE  Ccondition>,  then  the  contextual  Crecord  type>  of 
each  Ccomponent  view  identifier>  in  the  Ccondition>  is  the  object  Crecord  type> 

2)  Every  Cset  view  name>  contained  within  a  Cfind  cursor  disposition>  shall  be  different  from  every  other 
Cset  view  name>  within  that  Cfind  cursor  disposition >. 

3)  A  Cset  view  name>  contained  in  a  C position  member >  shall  designate  a  Cset  type>  that  has  a  member 
Crecord  type>  identical  to  its  owner  Crecord  type>. 


9.  Data  manipulation  language  8 1 


AMERICAN  NATIONAL  STANDARD  X3. 133-1986 


4)  If  the  <find  intent>  is  omitted,  then  it  is  assumed  to  be  FOR  RETRIEVE. 

General  Rules 

1)  Locate  a  specific  record  occurrence  in  the  database,  determined  by  the  <find  specification >  as  follows: 

Case: 

a)  If  the  <find  specification >  is  a  <database  key  identifiers* ,  then: 

i)  The  object  <database  key>  is  the  <database  key>  referenced  by  the  <database  key  identifiers-. 

ii)  If  the  object  <database  keys*  is  null,  then  raise  exception  find:  database  key  is  null. 

iii)  Select  the  record  referenced  by  the  object  <database  key>. 

b)  If  the  <find  specifications-  is  a  <search  specifications-,  then: 

i)  Case: 

1.  If  the  <  domain  specification  >  is  a  <  record  type  domain  >,  then  the  domain  of  the  <  search 
specification  >  consists  of  all  record  occurrences  of  the  object  <  record  type>  of  the  <  search 
specification  >.  The  ordering  of  the  record  occurrences  in  the  domain  is  implementor-defined. 
This  order  is  subject  to  the  reproducibility  requirement  within  a  transaction,  but  it  may  change 
between  transactions.  The  object-position  of  the  <search  specification >  is  the  <database 
keys-  of  the  <record  cursor>  designated  by  the  <record  view  name>. 

2.  If  the  <domain  specification >  is  a  <set  domains*,  then: 

A.  The  object  <set  cursor>  of  the  <set  domains-  is  the  <set  cursor>  designated  by  the  <set 
view  name>. 

B.  If  the  object  <set  type>  is  singular,  then  the  object  set  of  the  <set  domains*  is  the  one 
and  only  occurrence  of  the  object  <set  types*  in  the  database. 

If  the  object  <set  type>  is  not  singular,  then  the  object  set  of  the  <set  domain>  is  the  set 
referenced  by  the  <database  keys-  of  the  <owner>  of  the  object  <set  cursors*.  If  that 
<database  keys*  is  null,  then  raise  exception  find:  database  key  is  null. 

C.  The  domain  of  the  <search  specifications*  consists  of  all  record  occurrences  that  are 
members  of  the  object  set.  The  ordering  of  the  record  occurrences  in  the  domain  is  deter¬ 
mined  by  the  ordering  criteria  for  the  object  <set  type>. 

D.  The  object-position  of  the  <search  specifications*  is  the  <position>  of  the  object  <set 
cursor  >. 

3.  If  the  <domain  specification >  is  a  <subschema  domains*,  then  the  domain  of  the  <search 
specifications*  consists  of  all  record  occurrences  of  the  object  <record  type>s.  The  ordering 
of  record  occurrences  in  the  domain  is  implementor-defined.  This  order  is  subject  to  the 
reproducibility  requirement  within  a  transaction,  but  it  may  change  between  transactions. 

The  object-position  of  the  <search  specification >  is  the  <database  keys*  of  the  <session 
cursor >. 
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ii)  If  the  <search  orientation>  contains  a  <signed  integer>,  then  let  i  be  the  value  of  that  <signed 
integer >.  If  the  < search  orientation>  specifies  FIRST  or  NEXT,  then  let  i  be  +1.  If  the  < search 
orientation  >  specifies  LAST  or  PRIOR,  then  let  i  be  -1. 

iii)  If  NEXT,  PRIOR,  or  RELATIVE  is  specified  and  the  value  of  i  is  positive  (negative),  then: 

Case: 

1.  If  the  object-position  is  a  single  <database  key>  that  is  not  null,  then  remove  from  the 
domain  the  record  referenced  by  that  <  database  key>  and  all  record  occurrences  that  are 
ordered  before  (after)  that  record. 

2.  If  the  object-position  is  a  pair  of  <database  key>s  whose  second  (first)  <database  key>  is 
not  null,  then  remove  from  the  domain  all  record  occurrences  that  are  ordered  before  (after) 
the  record  referenced  by  that  <database  key>. 

3.  If  the  object-position  is  a  pair  of  <database  key>s  whose  second  (first)  <database  key>  is 
null,  then  remove  all  record  occurrences  from  the  domain. 

iv)  If  a  <set  domain  >  containing  a  <  record  view  name>  is  specified,  then  remove  from  the  domain 
all  record  occurrences  that  are  not  of  the  object  <  record  type>. 

v)  If  the  <search  specification >  contains  a  <condition>,  then  for  each  record  occurrence  in  the 
domain: 

1.  The  contextual  <database  key>  of  each  < component  view  identifier>  in  the  <condition>  is 
the  < database  key>  of  the  record  occurrence. 

2.  Evaluate  that  <condition>  for  the  record  occurrence. 

3.  If  the  <condition>  is  false,  then  remove  the  record  occurrence  from  the  domain. 

vi)  Let  n  be  the  number  of  record  occurrences  remaining  in  the  domain.  If  the  value  of  i  is  positive, 
then  let  j  be  i.  Otherwise,  let  j  be  n+i+ 1. 

If  j  is  greater  than  0  and  not  greater  than  n,  then  select  the  j-th  record  occurrence  of  the  domain. 
Otherwise,  raise  exception  find:  no  record  found. 

2)  If  the  <record  view  name>  of  the  selected  record  does  not  designate  a  <ready  specification>  in  the 
<ready  list>,  then  raise  exception  find:  record  not  ready.  If  the  <access  intent>  of  that  <ready  specifica- 
tion>  is  RETRIEVE  and  the  <find  intent>  specifies  UPDATE,  then  raise  exception  find:  record  not  ready 
for  update. 

3)  Set  the  <database  key>  of  the  <session  cursor>  to  the  <database  key>  of  the  selected  record. 

4)  If  the  <find  cursor  disposition>  is  omitted  or  it  specifies  neither  ALL  nor  RECORD,  then  set  the  data¬ 
base  key>  of  the  <record  cursor>  designated  by  the  <record  view  name>  of  the  selected  record  to  the 
database  key>  of  the  selected  record. 

5)  If  the  <find  cursor  disposition >  is  omitted  or  it  specifies  does  not  specify  ALL,  then  for  each  <set 
cursor >  whose  <set  view  name>  is  not  specified  in  a  <find  specific  retention>  in  the  <find  cursor  dispo¬ 
sition  >: 

Case: 
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a)  If  the  <  record  type>  of  the  selected  record  is  the  owner  <  record  type>  of  the  <set  type>  of  the  <set 
cursor>,  and  if  the  <set  view  name>  that  designates  the  <set  cursor>  is  not  specified  in  a  <position 
member>,  then  set  the  <owner>  of  that  <set  cursor>  to  the  <database  key>  of  the  selected  record, 
and  set  the  <position>  of  that  <set  cursor>  to  null. 

b)  If  the  <set  view  name>  of  the  <set  cursor>  is  specified  in  a  <position  member>  and  the  selected 
record  is  not  a  member  of  any  set  occurrence  of  the  <set  type>  designated  by  that  <set  view  name>, 
then  raise  exception  find:  no  record  found. 

c)  If  the  selected  record  is  a  member  of  a  set  occurrence  of  the  <set  type>  designated  by  the  <set  view 
name>  of  the  <set  cursor>,  then  if  either  the  <record  type>  of  the  selected  record  is  not  the  owner 
Crecord  type>  of  that  <set  type>  or  the  <set  view  name>  of  the  <set  cursor>  is  specified  in  a 
<position  member>,  then: 

i)  Set  the  <position>  of  the  <set  cursor>  to  the  <database  key>  of  the  selected  record. 

ii)  If  that  <set  type>  is  a  nonsingular  <set  type>,  then  set  the  <owner>  of  the  <set  cursor>  to  the 
<database  key>  of  the  owner  record  occurrence  of  that  set  occurrence. 

d)  Otherwise,  do  not  update  the  <set  cursor>. 
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9.6  <get  statement > 

Function 

Set  parameter  values  to  component  values  from  a  selected  record  occurrence. 

Format 

<get  statement>  ::  = 

GET  <to  parameter  move> 

Syntax  Rules 

None. 

General  Rules 

1)  The  object  record  is  the  record  referenced  by  the  <database  key>  of  the  <record  cursor>  designated  by 
the  <record  view  name>  of  the  <to  parameter  move>.  If  that  <database  key>  is  null,  then  raise  excep¬ 
tion  get:  record  cursor  is  null. 

2)  The  contextual  <database  key>  of  each  <component  view  identifier>  in  the  <to  parameter  move  clause> 
is  the  <database  key>  of  the  object  record. 

3)  Evaluate  all  <operand>s  in  the  <to  parameter  move>. 

4)  For  each  <to  parameter  move  clause>  in  the  <to  parameter  move>,  from  left  to  right: 

a)  Perform  the  data  transfer  specified  by  the  <to  parameter  move  clause>. 

b)  If  an  exception  is  raised  while  performing  the  data  transfer  for  the  <to  parameter  move  clause>,  then 
do  not  assign  a  value  to  the  parameter  designated  by  that  <to  parameter  move  clause  >,  do  not 
perform  any  subsequent  <to  parameter  move  clause>  of  the  <to  parameter  move>,  and  retain  the 
effect  of  prior  <to  parameter  move  clause>s  that  have  been  performed. 

5)  Set  the  <database  key>  of  the  <session  cursor>  to  the  <database  key>  of  the  object  record. 
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9.7  < modify  statement > 

Function 

Replace  the  contents  of  one  or  more  data  items  in  a  record  occurrence. 

Format 

< modify  statement >  ::  = 

MODIFY  <to  database  move> 

Syntax  Rules 

None. 

General  Rules 

1)  The  object  <  record  view  name>  is  the  <  record  view  name>  of  the  <to  database  move>.  The  object 

<  record  type>  is  the  <  record  type>  designated  by  the  object  <  record  view  name>. 

2)  If  the  object  <record  view  name>  does  not  designate  a  <ready  specification>  in  the  <ready  list>  having 
an  <access  intent>  of  UPDATE,  then  raise  exception  modify:  record  not  ready  for  update. 

3)  The  object  record  is  the  record  referenced  by  the  <database  key>  of  the  <record  cursor>  designated  by 
the  object  <record  view  name>.  If  that  <database  key>  is  null ,  then  raise  exception  modify:  record  cursor 
is  null. 

4)  A  modified  data  item  is  any  data  item  designated  by  a  Ccomponent  view  identifier>  in  a  target  identifier 
of  the  <to  database  move>. 

5)  The  contextual  <  database  key>  of  each  <  component  view  identifier >  in  the  <to  database  move>  is  the 

<  database  key>  of  the  object  record. 

6)  Evaluate  all  <  operand  >s  in  the  <to  database  move>. 

7)  For  each  <to  database  move  clause>  in  the  <to  database  move>,  perform  the  data  transfer  specified  by 
each  <to  database  move  clause  >  in  the  <to  database  move>. 

8)  For  each  <set  type>  of  which  the  object  <record  type>  is  a  member  <record  type>,  let  the  object 

<  member  clause  >  be  the  <member  clause  >  of  that  <set  type>  whose  member  <  record  type>  is  the 
object  Crecord  type>.  If  the  <insertion  clause>  of  the  object  Cmember  clause>  specifies  STRUC¬ 
TURAL,  and  if  a  modified  data  item  is  referenced  by  a  <component  identifier>  that  is  specified  as  a 
Cmember  component  identifier>  in  that  Cinsertion  clause>,  then: 

a)  Perform  the  Cremove  operation>  with  the  Cdatabase  key>  of  the  object  record  as  the  <remove 
record>,  and  the  <set  view  name>  of  the  <set  type>  as  the  Cremove  set  type>. 

b)  Let  D  be  the  cdatabase  key>  of  the  occurrence  of  the  Crecord  type>  designated  by  the  owner 
Crecord  view  name>  of  the  Cset  type>  that  has  values  for  each  data  item  referenced  by  an  Cowner 
component  identifier>  of  a  Ccomponent  identifier  match>  of  the  Cinsertion  clause>  equal  to  the 
value  of  the  data  item  in  the  object  record  that  is  referenced  by  the  Cmember  component  identifier> 
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of  that  <component  identifier  match>.  If  there  is  no  such  record  occurrence,  then  raise  exception 
modify:  no  match  for  set  insertion. 

c)  Perform  the  <insert  operation>  with  the  <database  key>  of  the  object  record  as  the  Cinsert  record>, 
the  <set  name>  of  the  <set  type>  as  the  Cinsert  set  type>,  the  Cdatabase  key>  D  as  the  Cinsert  set 
owner>,  and  retain  as  the  cinsert  cursor  dispositions 

d)  If  the  C  retention  clause  >  of  the  object  C  member  clause  >  specifies  FIXED  and  the  set  occurrence 
into  which  the  object  record  was  inserted  is  not  the  set  occurrence  from  which  it  was  removed,  then 
raise  exception  modify:  retention  is  fixed. 

9)  If  the  object  record  is  currently  a  member  of  a  set  of  a  Cset  type>  for  which  the  preceding  General  Rule 
does  not  apply,  and  a  modified  component  is  designated  by  a  Ccomponent  identifier>  in  a  Ckey  clause> 
of  the  Cset  type>,  then: 

a)  Perform  the  Cremove  operation>  with  the  Cdatabase  key>  of  the  object  record  as  the  Cremove 
record>  and  the  Cset  name>  of  the  Cset  type>  as  the  Cremove  set  type>. 

b)  Perform  the  Cinsert  operation>  with  the  cdatabase  key>  of  the  object  record  as  the  Cinsert  record>, 
the  Cset  name>  of  the  Cset  type>  as  the  Cinsert  set  type>,  retain  as  the  Cinsert  cursor  dispositions 
and: 

Case: 

i)  If  the  Cset  type>  is  a  singular  Cset  type>,  then  null  as  the  cinsert  set  owners 

ii)  If  the  Cset  type>  is  not  a  singular  Cset  types  then  the  Cdatabase  key>  of  the  owner  of  the  set 
from  which  the  object  record  was  removed  as  the  Cinsert  set  owner >. 

10)  If  execution  of  the  Cmodify  statement>  would  cause  a  Crecord  uniqueness  clauses  Cmember  uniqueness 
clauses  Ckey  clauses  or  Corder  clause>  to  be  violated,  then  raise  exception  modify:  duplicates  are  pro¬ 
hibited.  If  it  would  cause  a  Crecord  check  clause>  to  be  violated,  then  raise  exception  modify:  record  check 
violated.  If  it  would  cause  a  Cmember  check  clause>  to  be  violated,  then  raise  exception  modify:  member 
check  violated. 
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9.8  < nullify  cursor  statement > 

Function 

Set  the  referenced  cursor  to  null. 

Format 

<  nullify  cursor  statement  >  ::  = 

NULLIFY  <database  key  identifier> 

Syntax  Rules 

None. 

General  Rules 

1)  Case: 

a)  If  the  <database  key  identifier>  specifies  SESSION,  then  set  the  <database  key>  of  the  <session 
cursor>  to  null. 

b)  If  the  <database  key  identifier>  specifies  a  <record  view  name>,  then  set  the  <database  key>  of  the 
<record  cursor>  designated  by  the  <record  view  name>  of  the  <nullify  cursor  statement>  to  null. 

c)  If  the  <database  key  identifier>  specifies  OWNER,  then  set  both  the  <owner>  and  the  <position> 
of  the  <set  cursor>  designated  by  the  <set  view  name>  of  the  <nullify  cursor  statement>  to  null. 

d)  If  the  <database  key  identifier>  specifies  MEMBER,  then  set  the  <position>  of  the  <set  cursor> 
designated  by  the  <set  view  name>  of  the  <nullify  cursor  statement>  to  null. 
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9.9  <ready  statements 

Function 

Prepare  one  or  more  Crecord  type>s  for  processing. 

Format 

<ready  statement >  ::  = 

READY  <ready  specif ication>... 

<ready  specification >  ::  = 

<  record  view  name> 

<  share  specification  > 

< access  intent > 

<share  specification>  ::  = 

EXCLUSIVE  |  PROTECTED  |  SPLARED 

<access  intent>  ::  = 

RETRIEVE  |  UPDATE 

Syntax  Rules 

1)  The  same  Crecord  view  name>  shall  not  be  specified  more  than  once  in  a  <ready  statements*. 

General  Rules 

1)  If  a  Crecord  view  name>  in  the  Cready  statement>  designates  a  Cready  specification >  in  the  Cready 

hst>,  then  raise  exception  ready:  record  already  ready. 

2)  If  any  of  the  following  conditions  is  true,  then  raise  exception  ready:  lock  conflict. 

a)  A  Cready  specification >  has  a  Cshare  specification >  that  is  EXCLUSIVE  and  a  Crecord  view 
name>  that  is  contained  in  the  Cready  list>  of  a  concurrent  Csession  state>. 

b)  One  or  more  of  the  Crecord  view  name>s  is  contained  in  the  Cready  list>  of  a  concurrent  Csession 
state >  with  a  Cshare  specif ication>  that  is  EXCLUSIVE. 

c)  A  Cready  specification>  has  a  Cshare  specification>  that  is  SHARED,  an  Caccess  intent>  that  is 
UPDATE,  and  a  Crecord  view  name>  that  is  specified  in  the  Cready  list>  of  a  concurrent  Csession 
state>  with  a  Cshare  specification>  that  is  PROTECTED. 

d)  A  Cready  specification>  has  a  Cshare  specification >  that  is  PROTECTED,  an  Caccess  intent>  that 
is  UPDATE,  and  a  Crecord  view  name>  that  is  specified  in  the  Cready  list>  of  a  concurrent  Csession 
state>  with  a  Cshare  specification>  of  PROTECTED  or  with  an  Caccess  intent>  of  UPDATE. 

e)  A  Cready  specification>  has  a  Cshare  specification>  that  is  PROTECTED,  an  Caccess  intent>  that 
is  RETRIEVE,  and  a  Crecord  view  name>  that  is  specified  in  the  Cready  list>  of  a  concurrent 
Csession  state>  with  an  Caccess  intent>  of  UPDATE. 

3)  Append  the  Cready  specification^  to  the  Cready  list>  of  the  Csession  state>. 
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9.10  <  reconnect  statement  > 

Function 

Change  the  membership  of  a  record  occurrence  in  a  <  set  type> 

Format 

< reconnect  statement >  ::  = 

RECONNECT  <database  key  identifier>  IN  <set  view  name> 

Syntax  Rules 

1)  An  eligible  <record  type>  is  a  <record  type>  that  is  defined  as  a  member  <record  type>  in  the  <set 
type>  designated  by  the  <set  view  name>. 

2)  If  the  <database  key  identifier>  specifies  a  <record  view  name>,  then  that  Crecord  view  name>  shall 
designate  an  eligible  <record  type>. 

General  Rules 

1)  The  object  <database  key>  is  the  <database  key>  referenced  by  the  <database  key  identifiers  If  that 
<database  key>  is  null,  then  raise  exception  reconnect:  database  key  is  null. 

The  object  <record  type>  is  the  Crecord  type>  referenced  by  the  object  cdatabase  key>. 

2)  If  the  Crecord  view  name>  of  the  object  Crecord  type>  does  not  designate  a  C ready  specification >  in  the 
Cready  list>  having  an  Caccess  intent>  of  UPDATE,  then  raise  exception  reconnect:  record  not  ready  for 
update. 

3)  If  the  object  Crecord  type>  is  not  an  eligible  Crecord  type>,  then  raise  exception  reconnect:  ineligible 
record  type. 

4)  Perform  the  Cremove  operation>  with  the  object  cdatabase  key>  as  the  Cremove  record>  and  the  Cset 
view  name>  of  the  Creconnect  statement>  as  the  Cremove  set  type>. 

5)  Perform  the  Cinsert  operation>  with  the  object  Cdatabase  key>  as  the  Cinsert  record>,  the  Cset  view 
name>  of  the  Creconnect  statement>  as  the  Cinsert  set  type>,  the  Cdatabase  key>  of  the  Cowner>  of 
the  Cset  cursor>  designated  by  the  Cset  view  name>  of  the  Creconnect  statement>  as  the  Cinsert  set 
owner>,  and  update  as  the  Cinsert  cursor  disposition >. 

6)  If  the  object  Crecord  type>  has  a  Cretention  clause>  specifying  FIXED  in  the  Cset  type>  designated  by 
the  Cset  view  name>,  and  the  set  into  which  the  object  record  was  inserted  is  not  the  set  from  which  it 
was  removed,  then  raise  exception  reconnect:  retention  is  fixed. 
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9.11  <  rollback  statement  > 

Function 

Terminate  the  current  transaction  with  rollback. 

Format 

< rollback  statement >  ::  = 

ROLLBACK  [FINISH] 

Syntax  Rules 

None. 

General  Rules 

1)  Terminate  the  current  transaction.  Cancel  the  effect  on  the  database  of  all  statements  executed  by  the 
session  during  that  transaction. 

2)  Set  the  <cursors>  to  the  initial  <cursors>  for  the  subject  <subschema>. 

3)  For  each  ctemporary  set>  in  the  <temporary  sets>,  remove  each  member  record  from  membership  in 
that  set. 

4)  If  FINISH  is  specified,  then  set  the  <ready  list>  to  empty. 
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9.12  <  store  statement  > 

Function 

Store  a  record  in  the  database. 

Format 

< store  statement >  — 

STORE  <to  database  move>  [<store  retention>] 

<  store  retention  >  ::  = 

RETAIN  ALL 
|  RETAIN  RECORD 
|  RETAIN  SET  <set  view  name>... 

|  RETAIN  RECORD  SET  <set  view  name>... 

Syntax  Rules 

1)  The  object  <  record  view  name>  is  the  <  record  view  name>  of  the  <to  database  move>.  The  object 
<record  type>  is  the  <record  type>  designated  by  the  object  <record  view  name>.  The  object  <record 
view>  is  the  < record  view>  designated  by  the  object  < record  view  name>. 

2)  Each  < component  type>  in  the  object  <record  type>  that  is  not  designated  by  a  < component  view 
name>  in  the  object  <  record  view>  shall  contain  a  <  default  clause  >. 

3)  Each  <  component  type>  in  the  object  <  record  type>  that  is  not  designated  by  the  <  component  view 
name>  of  a  target  <component  view  identifier>  in  the  <to  database  move>  shall  contain  a  <default 
clause  >. 

4)  The  subject  < subschema >  shall  include  a  <set  view>  for  each  <set  type>  in  which  the  object  Crecord 
type>  is  defined  as  a  member  Crecord  type>  with  an  < insertion  clause>  that  specifies  AUTOMATIC. 

5)  Every  <set  view  name>  contained  within  a  Cstore  retention>  shall  be  different  from  every  other  <set 
view  name>  within  that  < store  retention>. 

6)  For  each  <set  view  name>  specified  in  a  Cstore  retention>,  the  object  Crecord  type>  shall  be  either  a 
member  Crecord  type>  or  owner  Crecord  type>  of  the  Cset  type>  referenced  by  that  Cset  view  name>. 

General  Rules 

1)  If  the  object  Crecord  view  name>  does  not  designate  a  Cready  specification>  in  the  Cready  list>  having 
an  C  access  intent>  of  UPDATE,  then  raise  exception  store:  record  not  ready  for  update. 

2)  Create  in  the  database  a  record  occurrence  of  the  object  Crecord  type>.  The  new  record  occurrence  is 
the  object  record.  The  object  record  assumes  an  implementor-defined  position  relative  to  other  record 
occurrences,  and  the  relative  order  of  the  other  occurrences  remains  unchanged. 

NOTE:  The  construction  of  a  new  record  occurrence  is  specified  in  the  General  Rules  of  6.8,  “cdefault 
clause >”  on  page  38. 
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3)  The  contextual  <database  key>  of  each  <component  view  identifier>  in  the  <to  database  move  clause> 
is  the  <database  key>  of  the  object  record. 

4)  Evaluate  all  <operand>s  in  the  <to  database  move>. 

5)  For  each  <to  database  move  clause>  in  the  <to  database  move>,  perform  the  data  transfer  specified  by 
each  <to  database  move  clause  >  in  the  <to  database  move>. 

6)  Establish  the  object  record  as  the  owner  of  an  empty  set  for  each  <set  type>  in  which  the  object  <record 
type>  is  the  owner  <  record  type>. 

7)  For  each  <set  type>  of  which  the  object  <record  type>  is  a  member  <record  type>: 

a)  Let  the  object  <member  clause>  be  the  <member  clause>  of  that  <set  type>  whose  member 
<  record  type>  is  the  object  <  record  type>. 

b)  If  the  <store  retention>  specifies  ALL,  or  if  the  <set  type>  is  designated  by  a  <set  view  name>  in 
the  <store  retention>,  then  let  C  be  retain.  Otherwise,  let  C  be  update. 

c)  Case: 

i)  If  the  Cinsertion  clause>  of  the  object  <member  clause>  specifies  AUTOMATIC,  then  perform 
the  Cinsert  operation>  with  the  <database  key>  of  the  object  record  as  the  <insert  record>,  the 
<set  name>  of  the  <set  type>  as  the  Cinsert  set  type>,  the  Cdatabase  key>  of  the  <owner>  of 
the  <set  cursor>  whose  <set  view  name>  designates  the  <set  type>  as  the  Cinsert  set  owner>, 
and  C  as  the  Cinsert  cursor  disposition >. 

ii)  If  the  Cinsertion  clause>  of  the  object  Cmember  clause>  specifies  STRUCTURAL,  then: 

1.  Let  D  be  the  Cdatabase  key>  of  the  occurrence  of  the  owner  C record  type>  of  the  Cset 
type>  that  has  values  for  each  data  item  referenced  by  an  Cowner  component  identifier>  of  a 
C component  identifier  match >  of  the  Cinsertion  clause >  equal  to  the  value  of  the  data  item 
in  the  record  occurrence  being  stored  that  is  referenced  by  the  Cmember  component  identi¬ 
fier  >  of  that  Ccomponent  identifier  match>.  If  there  is  no  such  record  occurrence,  then  raise 
exception  store:  no  match  for  set  insertion. 

2.  Perform  the  Cinsert  operation >  with  the  Cdatabase  key>  of  the  object  record  as  the  Cinsert 
record>,  the  Cset  name>  of  the  Cset  type>  as  the  Cinsert  set  type>,  the  Cdatabase  key>  D 
as  the  Cinsert  set  owner>,  and  C  as  the  Cinsert  cursor  dispositions 

iii)  If  the  Cinsertion  clause>  of  the  object  Cmember  clause>  specifies  MANUAL,  then  do  not  insert 
the  object  record  in  any  occurrence  of  the  Cset  type>. 

8)  Set  the  Csession  cursor>  to  reference  the  object  record. 

9)  If  the  Cstore  retention>  specifies  neither  ALL  nor  RECORD,  then  set  the  Crecord  cursor>  designated  by 
C  record  view  name>  to  reference  the  object  record. 

If  the  Cstore  retention>  does  not  specify  ALL,  then  for  each  Cset  type>  designated  by  a  Cset  view>  in 
the  subject  Csubschema>  in  which  the  object  Crecord  type>  is  the  owner  Crecord  type>,  if  that  Cset 
type>  is  not  designated  by  a  Cset  view  name>  in  the  Cstore  retentions  then  set  the  Cowner>  of  the 
Cset  cursor>  for  that  Cset  type>  to  the  cdatabase  key>  of  the  object  record  and  set  the  Cposition>  of 
that  Cset  cursor>  to  null. 
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10)  If  execution  of  the  <  store  statement>  would  cause  a  <  record  uniqueness  clause  >  to  be  violated,  then  raise 
exception  store:  duplicates  are  prohibited.  If  it  would  cause  a  <record  check  clause>  to  be  violated,  then 
raise  exception  store:  record  check  violated. 
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9.13  <test  database  key  equal  statement  > 

Function 

Determine  whether  two  <database  key>s  reference  the  same  record. 

Format 

<test  database  key  equal  statement  >  ::  = 

TEST  <  operand  1>  =  <  operand  2> 

< operand  1>  ::=  < database  key  identifier > 

<operand2>  ::=  < database  key  identifier> 

Syntax  Rules 

None. 

General  Rules 

1)  If  the  <database  key>  referenced  by  <operand  1  >  or  <operand  2>  is  null,  then  raise  exception  test:  data¬ 
base  key  is  null. 

2)  If  the  <database  key>  referenced  by  <operand  1>  and  the  <database  key>  referenced  by  <operand  2> 
reference  the  same  record  occurrence,  then  set  the  value  of  the  TEST  parameter  to  "1".  Otherwise,  set  the 
value  of  the  TEST  parameter  to  "0". 
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9.14  <test  database  key  null  statement  > 

Function 

Determine  whether  a  <database  key>  is  null. 

Format 

<test  database  key  null  statement >  ::  = 

TEST  NULL  <database  key  identifier> 

Syntax  Rules 

None 

General  Rules 

1)  If  the  <database  key>  referenced  by  the  <database  key  identifier>  is  null,  then  set  the  value  of  the  TEST 
parameter  to  "1".  Otherwise,  set  the  value  of  the  TEST  parameter  to  "0". 
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9.15  < test  set  empty  statement  > 

Function 

Determine  whether  a  set  has  any  member  records. 

Format 

<test  set  empty  statement >  = 

TEST  SET  EMPTY  <set  view  name> 

Syntax  Rules 

1)  The  object  <set  type>  is  the  <set  type>  designated  by  <set  view  name>.  The  object  <set  cursor>  is  the 
<set  cursor>  designated  by  <set  view  name>. 

General  Rules 

1)  Case: 

a)  If  the  object  <set  type>  is  a  singular  <set  type>,  then  the  object  set  is  the  one-and-only  occurrence 
of  the  object  <set  type>. 

b)  If  the  object  <set  type>  is  a  nonsingular  <set  type>,  then: 

Case: 

i)  If  the  <owner>  of  the  object  <set  cursor>  is  null,  then  raise  exception  test:  set  cursor  is  null. 

ii)  If  the  <owner>  of  the  object  <set  cursor>  is  not  null,  then  the  object  set  is  the  set  referenced  by 
the  object  <set  cursor>. 

2)  If  the  object  set  has  one  or  more  members  whose  <record  type>  is  included  in  the  subject  <subschema>, 
then  set  the  value  of  the  TEST  parameter  to  "0".  Otherwise,  set  the  value  of  the  TEST  parameter  to  "1". 
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9.16  <test  set  membership  statement  > 

Function 

Determine  whether  a  record  is  a  member  of  some  occurrence  of  a  <set  type>. 

Format 

<test  set  membership  statement>  = 

TEST  SET  <set  view  name>  CONTAINS  <database  key  identifier> 

Syntax  Rules 

None. 

General  Rules 

1)  The  object  <database  key>  is  the  <database  key>  referenced  by  the  <database  key  identifier>.  If  the 
object  <database  key>  is  null,  then  raise  exception  test:  database  key  is  null. 

2)  If  the  <record  type>  of  the  record  referenced  by  the  object  <database  key>  is  not  defined  as  a  member 
<record  type>  of  the  <set  type>  designated  by  <set  view  name>,  then  raise  exception  test:  ineligible 
record  type. 

3)  If  the  record  referenced  by  the  object  <database  key>  is  a  member  of  an  occurrence  of  the  <set  type> 
designated  by  <set  view  name>,  then  set  the  value  of  the  TEST  parameter  to  "1".  Otherwise,  set  the 
value  of  the  TEST  parameter  to  "0". 
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9.17  <  database  key  identifier  > 

Function 

Reference  a  <database  key>. 

Format 

<database  key  identifier>  ::  = 

SESSION 

|  <  record  view  name> 

|  {OWNER  |  MEMBER}  <set  view  name> 


Syntax  Rules 

1)  If  the  <database  key  identifier>  specifies  OWNER,  then  the  <set  type>  designated  by  the  <set  view 
name>  shall  not  be  a  singular  <set  type>. 

General  Rules 

1)  Case: 

a)  If  SESSION  is  specified,  then  the  <database  key  identifier>  references  the  <database  key>  of  the 
<session  cursor>. 

b)  If  a  <record  view  name>  is  specified,  then  the  <database  key  identifier>  references  the  <database 
key>  of  the  <record  cursor>  designated  by  the  <record  view  name>  of  the  <database  key  identi¬ 
fier  >. 

c)  If  OWNER  is  specified,  then  the  <database  key  identifier>  references  the  <database  key>  of  the 
<owner>  of  the  <set  cursor>  designated  by  the  <set  view  name>  of  the  <database  key  identifiers 

d)  If  MEMBER  is  specified,  then 

i)  The  object  <position>  is  the  <position>  of  the  <set  cursor>  designated  by  the  <set  view  name> 
of  the  <database  key  identifier>. 

ii)  If  the  object  <position>  is  a  single  <database  key>,  then  the  <database  key  identifier>  refer¬ 
ences  that  <  database  key>. 

If  the  object  <position>  is  a  pair  of  <database  key>s,  then  the  <database  key  identifier>  refer¬ 
ences  null. 
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)  9.18  <  component  view  identifier > 

Function 

Reference  a  component  or  data  item. 

Format 

<  component  view  identifier  >  ::  = 

<dot  style  component  view  identifier > 

|  <of  style  component  view  identifier> 

<dot  style  component  view  identifier >  ::  = 

[<record  view  name>.]  <component  view  name>  [< subscripts >]  [CURSOR] 

<of  style  component  view  identifier >  ::  = 

<  component  view  name>  [<  subscripts  >] 

[OF  <record  view  name>]  [CURSOR] 

Syntax  Rules 

1)  The  contextual  <  record  type>  of  a  <  component  view  identifier  >  is  specified  in  the  Syntax  Rules  of  the 
<NDL  statement>  that  contains  the  <component  view  identifiers 

^  2)  Case: 

a)  If  a  <component  view  identifier>  does  not  specify  CURSOR,  then  the  Ccomponent  view  identifier> 
shall  designate  a  <component  type>  of  the  contextual  <record  type>,  and  the  <record  view  name>, 
if  specified,  shall  designate  the  contextual  <record  type>.  The  subject  <record  type>  of  the  Com¬ 
ponent  view  identifier>  is  the  contextual  <record  type>. 

b)  If  a  Ccomponent  view  identifier>  specifies  CURSOR,  then  it  shall  specify  a  Crecord  view  name>, 
and  the  subject  Crecord  view>  is  the  Crecord  view>  designated  by  that  Crecord  view  name>. 

3)  The  Ccomponent  view  name>  shall  designate  a  Ccomponent  type>  of  the  subject  Crecord  type>.  That 
Ccomponent  type>  is  the  subject  Ccomponent  type>. 

4)  If  a  Ccomponent  view  identifier>  contains  Csubscripts>,  then: 

a)  The  subject  Ccomponent  type>  shall  define  an  array. 

b)  The  contextual  C  occurs  clause  >  of  the  C  subscripts  >  is  the  C  occurs  clause  >  contained  in  the  subject 
Ccomponent  type>. 

General  Rules 

1)  The  contextual  Cdatabase  key>  of  a  Ccomponent  view  identifier>  is  specified  in  the  General  Rules  of  the 
statement  that  contains  the  Ccomponent  view  identifiers 

|  2)  Case: 
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a)  If  a  <component  view  identifier>  specifies  CURSOR,  then  the  subject  <database  key>  is  the  data¬ 
base  key>  of  the  <record  cursor>  whose  <record  view  name>  designates  the  subject  <record  type>. 
If  that  database  key>  is  null,  then  raise  exception  cursor  reference:  database  key  is  null. 

b)  If  a  <component  view  identifier>  does  not  specify  CURSOR,  then  the  subject  database  key>  is  the 
contextual  <  database  key>. 

3)  A  <component  view  identifier>  references  a  data  item  or  array  in  the  record  referenced  by  the  subject 

database  key>,  as  follows: 

Case: 

a)  If  the  subject  <component  type>  of  a  < component  view  identifier>  defines  a  data  item,  then  the 
<component  view  identifier>  references  that  data  item. 

b)  If  the  subject  < component  type>  of  a  < component  view  identifier>  defines  an  array  and  the  < com¬ 
ponent  view  identifier>  does  not  contain  <  subscripts  >,  then  the  domponent  view  identifier>  refer¬ 
ences  that  array. 

c)  If  the  subject  < component  type>  of  a  < component  view  identifier >  defines  an  array  and  the  < com¬ 
ponent  view  identifier>  contains  < subscripts >,  then  the  < component  view  identifier >  references  the 
i-th  data  item  in  the  array,  where  i  is  the  value  of  the  <  subscripts  >. 
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9.19  <  parameter  identifier > 

Function 

Reference  a  parameter  item. 

Format 

<parameter  identifier>  ::  = 

<  parameter  name>  [<  subscripts  >] 

Syntax  Rules 

1)  The  object  <parameter  declaration>  of  a  <parameter  identifier>  is  the  <parameter  declaration>  desig¬ 
nated  by  the  <parameter  name>  of  the  <parameter  identifiers 

2)  If  the  object  <parameter  declaration>  does  not  contain  an  <occurs  clause>,  then  <subscripts>  shall  not 
be  specified. 

If  the  object  <  parameter  declaration>  contains  an  <  occurs  clause  >  and  a  <  subscripts  >  is  specified,  then 
that  <  occurs  clause  >  is  the  contextual  <  occurs  clause  >  of  the  <  subscripts  >. 

General  Rules 

1)  Case: 

a)  If  a  <subscripts>  is  not  specified,  then  the  <parameter  identifier>  references  the  data  item  or  array 
supplied  as  the  parameter  corresponding  with  the  object  <parameter  declarations 

b)  If  a  <subscripts>  is  specified,  then  the  <parameter  identifier>  references  the  i-th  data  item  in  the 
array  supplied  as  the  parameter  corresponding  with  the  object  <parameter  declarations  where  i  is  the 
value  of  the  <  subscripts  >. 
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9.20  <to  parameter  move>  and  <to  database  move> 


Format 

<to  parameter  move>  ::  = 

< record  view  name>  <to  parameter  move  clause >... 

<to  parameter  move  clause >  ::  = 

SET  <  parameter  identifier  >  TO  <  operand  > 

<to  database  move>  ::  = 

< record  view  name>  [<to  database  move  clause >...] 

<to  database  move  clause >  ::  = 

SET  Ccomponent  view  identifier>  TO  <operand> 

Syntax  Rules 

1)  For  a  <to  parameter  move>,  the  target  identifier  is  the  <parameter  identifier>.  For  a  <to  database 
move>  the  target  identifier  is  the  Ccomponent  view  identified. 

2)  Let  a  move  be  either  a  <to  parameter  move>  or  a  <  to  database  move>.  Let  a  move  clause  be  either  a 
<to  parameter  move  clause  >  or  a  <to  database  move  clause  >. 

3)  The  object  <  record  type>  of  the  move  and  the  contextual  <  record  type>  of  each  <  component  view  iden¬ 
tified  in  the  move  is  the  <record  type>  designated  by  the  <record  view  name>. 

4)  Case: 

a)  If  the  type  of  the  target  identifier  of  a  move  clause  is  character  string,  then  the  type  of  the  source 

<  operand  >  shall  be  character  string. 

b)  If  the  type  of  the  target  identifier  of  a  move  clause  is  exact  numeric,  then  the  type  of  the  source 

<  operand  >  shall  be  exact  numeric. 

c)  If  the  type  of  the  target  identifier  of  a  move  clause  is  approximate  numeric,  then  the  type  of  the  source 

<  operand  >  shall  be  approximate  numeric  or  exact  numeric. 

5)  Case: 

a)  If  the  target  identifier  of  a  move  clause  references  a  data  item  or  a  data  item  of  an  array,  then  the 

<  operand  >  of  that  move  clause  shall  be  a  data  item. 

b)  If  the  target  identifier  of  a  move  clause  references  an  array,  then  the  <operand>  of  that  move  clause 
shall  be  an  array. 

6)  No  ccomponent  view  identified  that  is  a  target  identifier  shall  specify  CURSOR.  If  a  Ccomponent  view 
identifier >  that  is  a  target  identifer  specifies  a  C  record  view  name>,  then  that  C  record  view  name>  shall 
be  the  same  as  the  C  record  view  name>  of  the  Cto  database  move>. 

7)  A  Ccomponent  view  identified  that  is  contained  in  an  Coperand>  of  the  Cto  database  move>  shall 
specify  CURSOR. 
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General  Rules 

1 )  The  target  item  is  the  item  referenced  by  the  target  identifier.  The  source  value  is  the  value  of  the  source 
<  operand  >. 

2)  Case: 


a)  If  the  type  of  the  target  item  is  character  string  of  length  L,  then: 

Case: 

i)  If  the  length  of  the  source  value  is  L,  then  set  the  target  item  to  the  source  value. 

ii)  If  the  length  of  the  source  value  is  M,  and  M>L,  then  if  the  last  M-L  characters  of  the  source 
value  are  space  characters,  then  set  the  target  item  to  the  first  L  characters  of  the  source  value; 
otherwise,  raise  exception  data  transfer:  string  truncation. 

iii)  If  the  length  of  the  source  value  is  M,  and  M<L,  then  set  the  first  M  characters  of  the  target  item 
to  the  source  value,  and  set  the  last  L-M  characters  of  the  target  item  to  space  characters. 

b)  If  the  type  of  the  target  item  is  exact  numeric  and  the  source  value  can  be  represented  exactly  as  a 
value  of  the  target  item  data  type,  then  set  the  target  item  to  that  value;  otherwise,  raise  exception  data 
transfer:  numeric  truncation. 

c)  If  the  type  of  the  target  item  is  approximate  numeric,  then  set  the  target  item  to  the  approximate 
numeric  value  of  the  source  value. 
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10.  Auxiliary  operations 


10.1  <insert  operation> 

Function 

Insert  a  record  occurrence  into  a  set. 

Format 

Cinsert  operation>  ::  = 

<  insert  record  > 

<  insert  set  type> 

<  insert  set  owner  > 

<  insert  cursor  disposition  > 

Cinsert  record>  ::  = 

Cdatabase  key> 

Cinsert  set  type>  ::  = 

Cset  name>  |  Cset  view  name> 

Cinsert  set  owner >  ::  = 

Cdatabase  key> 

Cinsert  cursor  disposition>  ::  = 
retain  |  update 

Syntax  Rules 

None. 

General  Rules 

1)  The  object  record  is  the  record  referenced  by  the  Cdatabase  key>  of  the  Cinsert  record>.  The  object 
Crecord  type>  is  the  Crecord  type>  of  the  object  record.  The  object  Cset  type>  is  the  Cset  type>  desig¬ 
nated  by  the  Cset  name>  or  Cset  view  name>  of  the  Cinsert  set  type>.  The  object  Cset  cursor>,  if  any, 
is  the  Cset  cursor>,  if  any,  whose  Cset  view  name>  designates  the  object  cset  type>. 

2)  If  the  object  record  is  already  a  member  of  an  occurrence  of  the  object  Cset  type>,  then  raise  exception 
insert:  record  already  a  member  of  set. 

3)  Case: 

a)  If  the  object  Cset  type>  is  a  singular  Cset  type>,  then  the  object  set  is  the  one-and-only  occurrence 
of  the  object  Cset  type>. 

b)  If  the  object  Cset  type>  is  not  a  singular  Cset  type>,  then  the  object  set  is  the  occurrence  of  the 
object  Cset  type>  that  is  owned  by  the  record  occurrence  referenced  by  the  Cdatabase  key>  of  the 
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Cinsert  set  owner>.  If  that  <database  key>  is  null ,  then  raise  exception  insert:  set  cursor  is  null.  If 
the  <  order  clause  >  of  the  object  <set  type>  specifies  NEXT  or  PRIOR,  then: 

i)  If  there  is  no  object  <set  cursor >,  then  raise  exception  insert:  set  is  not  in  subschema. 

ii)  If  the  object  set  is  not  the  set  occurrence  referenced  by  the  object  <set  cursor>,  then  raise  excep¬ 
tion  insert:  record  not  member  of  set. 

4)  Insert  the  object  record  as  a  member  of  the  object  set  in  accordance  with  the  set  ordering  criteria  specified 
by  the  <  order  clause  >  or  the  <key  clause  >s  of  the  object  <set  type>.  The  relative  order  of  other 
members  of  the  object  set  remains  unchanged. 

5)  If  the  <order  clause>  of  the  object  <set  type>  specifies  NEXT  (PRIOR),  then: 

Case: 

a)  If  the  <position>  of  the  object  <set  cursor>  is  a  single  <database  key>  that  is  not  null,  then  insert 
the  object  record  as  a  member  record  in  the  object  set  immediately  after  (before)  the  member  record 
referenced  by  that  <  database  key>. 

b)  If  the  <position>  of  the  object  <set  cursor>  is  a  single  <database  key>  that  is  null,  then  insert  the 
object  record  as  the  first  (last)  member  record  in  the  set  occurrence  referenced  by  that  <set  cursor>. 

c)  If  the  <position>  of  the  object  <set  cursor>  is  a  pair  of  <database  key>s  and  the  first  (second)  of 

those  <database  key>s  is  not  null,  then  insert  the  object  record  immediately  after  (before)  the 

member  record  referenced  by  that  first  (second)  <database  key>. 

d)  If  the  <position>  of  the  object  <set  cursor>  is  a  pair  of  <database  key>s  and  the  first  (second)  of 

those  <database  key>s  is  null,  then  insert  the  object  record  as  the  first  (last)  member  record  in  the  set 

occurrence  referenced  by  that  <set  cursor>. 

6)  If  the  <insert  operation>  would  cause  a  <member  uniqueness  clause>,  an  <order  clause>,  or  a  <key 
clause >  in  the  object  <set  type>  to  be  violated,  then  raise  exception  insert:  duplicates  are  prohibited.  If  it 
would  cause  a  <  member  check  clause  >  or  an  implied  <  member  check  clause  >  derived  from  the 
<  insertion  clause  >  to  be  violated,  then  raise  exception  insert:  member  check  violated. 

7)  If  there  is  an  object  <set  cursor>,  then: 

Case: 

a)  If  the  <insert  cursor  disposition>  is  update,  then  set  the  <position>  of  the  object  <set  cursor>  to  the 
<database  key>  of  the  object  record. 

b)  If  the  <insert  cursor  disposition>  is  retain  and  the  following  condition  is  true,  then  set  the  < position > 
of  the  object  <set  cursor>  to  the  <database  key>  of  the  object  record. 

Condition:  The  <position>  of  the  object  <set  cursor>  is  a  pair  of  <database  key>s  such  that 
either  the  first  such  <database  key>  references  a  record  that  immediately  precedes  the  object 
record  in  the  object  set  or  the  second  such  <database  key>  references  a  record  that  immediately 
follows  the  object  record  in  the  object  set. 
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10.2  < remove  operation > 

Function 

Remove  a  record  occurrence  from  a  set. 

Format 

< remove  operation >  = 

<  remove  record  > 

<  remove  set  type> 

<  remove  record  >  : :  -- 

<  database  key> 

< remove  set  type>  = 

<set  name>  |  <set  view  name> 

Syntax  Rules 

None. 

General  Rules 

1)  The  object  record  is  the  record  referenced  by  the  <database  key>  of  the  <remove  record>.  The  object 
<record  type>  is  the  <record  type>  of  the  object  record.  The  object  <set  type>  is  the  <set  type>  desig¬ 
nated  by  the  <set  name>  or  <set  view  name>  of  the  <  remove  set  type>. 

2)  The  object  set  is  the  occurrence  of  the  object  <set  type>  of  which  the  object  record  is  a  member.  If  the 
object  record  is  not  currently  a  member  of  any  occurrence  of  the  object  <set  type>,  then  raise  exception 
remove:  record  not  member  of  set. 

3)  If  there  is  a  < set  cursor >  whose  <set  view  name>  designates  the  object  <set  type>,  then: 

Case: 

a)  If  the  <position>  of  that  <set  cursor>  is  a  single  <database  key>  that  references  the  object  record, 
then: 

i)  If  there  is  a  record  occurrence  that  is  a  member  of  the  object  set  and  that  immediately  precedes  the 
object  record  in  that  set,  then  let  L  be  the  <database  key>  of  that  record  occurrence.  Otherwise, 
let  L  be  null. 

ii)  If  there  is  a  record  occurrence  that  is  a  member  of  the  object  set  and  that  immediately  follows  the 
object  record  in  that  set,  then  let  R  be  the  <database  key>  of  that  record  occurrence.  Otherwise, 
let  R  be  null. 

iii)  Set  the  <position>  of  that  <set  cursor>  to  the  pair  of  <database  key>s  L  and  R,  in  that  order. 

b)  If  the  <position>  of  that  <set  eursor>  is  a  pair  of  <database  key>s  the  first  (second)  of  which  refer¬ 
ences  the  object  record,  then: 
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i)  If  there  is  a  record  occurrence  that  is  a  member  of  the  object  set  and  that  immediately  precedes 
(follows)  the  object  record  in  that  set,  then  let  L  (R)  be  the  <database  key>  of  that  record  occur¬ 
rence.  Otherwise,  let  L  (R)  be  null. 

ii)  Replace  the  first  (second)  <database  key>  of  the  <position>  of  that  <set  cursor>  with  L  (R). 
c)  Otherwise,  do  nothing  to  that  <set  cursor>. 

4)  Remove  the  object  record  from  membership  in  the  object  set.  The  relative  order  of  other  members  of  the 
object  set  remains  unchanged. 
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11.  Interpretive  state 


11.1  <  session  state  > 

Format 

< session  state >  ::  = 

<  cursors  > 

<  temporary  sets> 

<ready  list> 

General  Rules 

1)  An  initial  <  session  state  >  for  a  <  module  >  contains  an  initial  <  cursors  >  for  the  <  module  >,  an  initial 
Ctemporary  sets>  for  the  Ctemporary  set  specifications >  of  the  <module>,  and  an  initial  <ready  list>. 
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11.2  <cursors> 

Format 

< cursors >  ::  = 

<session  cursor> 

[Crecord  cursor>...] 

[<set  cursor>...] 

<session  cursor >  ::  = 

<database  key> 

Crecord  cursor>  ::  = 

<  record  view  name>  <  database  key> 

<set  cursor >  = 

<set  view  name> 

<  owner  > 

<  position  > 

<owner>  ::=  <database  key> 

<position>  ::  = 

<  database  key> 

|  <database  key>  <database  key> 

<database  key>  ::  = 

See  General  Rule  1 . 

General  Rules 

1)  A  <  database  key>  is  an  implementation-defined  value  that  either  identifies  exactly  one  record  in  the  data¬ 
base  or  that  is  null  and  identifies  no  record. 

2)  The  Crecord  view  name>  of  a  Crecord  cursor>  designates  that  Crecord  cursor>.  The  Cset  view  name> 
of  a  Cset  cursor >  designates  that  Cset  cursor >. 

3)  An  initial  ccursors>  for  a  Cmodule>  contains: 

a)  An  initial  C session  cursor >. 

b)  An  initial  Crecord  cursor>  for  each  crecord  view>  of  the  subject  Csubschema>  of  the  Cmodule>. 

c)  An  initial  Cset  cursor>  for  each  Cset  view>  contained  in  the  subject  Csubschema>  of  the 
C  module  >. 

d)  An  initial  cset  cursor>  for  each  ctemporary  set  specification>  contained  in  the  Cmodule>. 

4)  An  initial  csession  cursor>  contains  a  cdatabase  key>  that  is  null. 

5)  An  initial  Crecord  cursor >  for  a  Crecord  view>  contains: 
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a)  A  <record  view  name>  equal  to  the  <record  view  name>  contained  in  the  <record  view>. 

b)  A  <database  key>  that  is  null. 

6)  An  initial  <set  cursor>  for  a  <set  view>  contains: 

a)  A  <set  view  name>  equal  to  the  <set  view  name>  contained  in  the  <set  view>. 

b)  An  <owner>  that  is  a  <database  key>  that  is  null. 

c)  A  <position>  that  is  a  <database  key>  that  is  null. 

7)  An  initial  <set  cursor>  for  a  < temporary  set  specification >  contains: 

a)  A  <set  view  name>  equal  to  the  <set  view  name>  contained  in  the  < temporary  set  specification^ 

b)  An  < owner >  that  is  a  <database  key>  that  is  null. 

c)  A  <position>  that  is  a  <database  key>  that  is  null. 

8)  The  <session  cursor>  references  the  record  referenced  by  the  <database  key>  of  the  <session  cursor>. 

A  <record  cursor>  references  the  record  referenced  by  the  <database  key>  of  the  <record  cursor>. 

If  the  <set  view  name>  of  a  <set  cursor  >  designates  a  nonsingular  <set  type>,  then  the  <set  cursor  > 
references  the  set  that  is  owned  by  the  record  occurrence  referenced  by  the  <database  key>  of  the 
<  owner  >  of  the  <set  cursor>. 

If  the  <set  view  name>  of  a  <set  cursor>  designates  a  singular  <set  type>,  then  the  <set  cursor>  refer¬ 
ences  the  one-and-only  occurrence  of  that  <set  type>  in  the  database  or  the  <  session  state  >. 
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1 1 .3  <temporary  sets> 

Format 

< temporary  sets>  = 

[< temporary  set>...] 

< temporary  set >  ::  = 

See  General  Rule  1 . 

General  Rules 

1)  A  <  temporary  set>  is  an  occurrence  of  a  temporary  <set  type>. 

2)  An  initial  <temporary  sets>  for  a  <temporary  set  specifications >  contains  an  empty  occurrence  of  each 
temporary  <set  type>  defined  in  the  <  temporary  set  specifications  >. 
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11.4  <readylist> 


Format 

<readylist>  ::=  empty  |  <ready  specif ication>... 

General  Rules 

1)  An  initial  <  ready  list>  contains  empty. 
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12.  Status  codes 


Figure  1  specifies  the  value  returned  in  the  STATUS  parameter  for  each  condition, 
(leftmost)  digit  of  all  current  and  future  status  codes  specified  for  NDL  shall  be  a 
that  the  second  digit  shall  be  either  "0"  or  "1".  Status  codes  of  the  form  "lxxxx", 
and  "l  lxxx",  are  reserved  for  implementor  use. 


It  is  intended  that  the  first 
value  other  than  "1",  and 
and  in  particular  "lOxxx" 


Value 

Condition 

01610 

array  reference:  subscript  out  of  bounds 

01810 

connect:  record  already  a  member 

01310 

connect:  database  key  is  null 

01330 

connect:  ineligible  record  type 

01920 

connect:  record  not  ready  for  update 

01310 

cursor  reference:  database  key  is  null 

01410 

data  transfer:  string  truncation 

01420 

data  transfer:  numeric  truncation 

01310 

disconnect:  database  key  is  null 

01330 

disconnect:  ineligible  record  type 

01920 

disconnect:  record  not  ready  for  update 

01310 

erase:  database  key  is  null 

01920 

erase:  record  not  ready  for  update 

01720 

erase:  set  has  mandatory  member 

01310 

find:  database  key  is  null 

00100 

find:  no  record  found 

01910 

find:  record  not  ready 

01920 

find:  record  not  ready  for  update 

01320 

get:  record  cursor  is  null 

01510 

insert:  duplicates  are  prohibited 

01860 

insert:  member  check  violated 

01810 

insert:  record  already  a  member 

01830 

insert:  record  not  member  of  set 

01340 

insert:  set  cursor  is  null 

01610 

insert:  set  is  not  in  subschema 

01320 

modify:  record  cursor  is  null 

01840 

modify:  record  check  violated 

01510 

modify:  duplicates  are  prohibited 

01860 

modify:  member  check  violated 

01230 

modify:  no  match  for  set  insertion 

01920 

modify:  record  not  ready  for  update 

01820 

modify:  retention  is  fixed 

OHIO 

procedure:  deadlock 

00000 

procedure:  success 

Figure  1  (Part  1  of  2).  STATUS  Values 
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Value 

Condition 

01940 

ready:  lock  conflict 

01950 

ready:  record  already  ready 

01310 

reconnect:  database  key  is  null 

01920 

reconnect:  record  not  ready  for  update 

01330 

reconnect:  ineligible  record  type 

01820 

reconnect:  retention  is  fixed 

01830 

remove:  record  not  member  of  set 

01840 

store:  record  check  violated 

01510 

store:  duplicates  are  prohibited 

01230 

store:  no  match  for  set  insertion 

01920 

store:  record  not  ready  for  update 

01310 

test:  database  key  is  null 

01330 

test:  ineligible  record  type 

01340 

test:  set  cursor  is  null 

Figure  1  (Part  2  of  2).  STATUS  Values 
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13.  Levels 

This  standard  specifies  two  levels.  Level  2  is  the  complete  NDL  database  language.  Level  1  is  the  subset  of 
Level  2  that  obeys  the  following  additional  rules. 

1)  6.3,  “< record  type >”  on  page  33  and  6.9,  “< record  check  clause >”  on  page  39: 

A  <  record  type>  shall  not  contain  a  <  record  check  clause  >. 

2)  6.14,  “<member  clause>”  on  page  45  and  6.20,  “< member  check  clause >”  on  page  54: 

A  <  member  clause  >  shall  not  contain  a  <  member  check  clause  >. 

3)  9.5,  “< find  statement >”  on  page  80: 

A  <find  statement  >  shall  not  contain  a  WHERE  <  condition  >. 

4)  Clause  8,  “Module  language”  on  page  65  and  8.3,  “<temporary  set  specifications >”  on  page  68: 

A  <module>  shall  not  contain  a  <temporary  set  specifications >. 

5)  6.16,  “< insertion  clause >”  on  page  47: 

An  <insertion  clause>  shall  not  contain  STRUCTURAL  <structural  specif ication>. 

6)  6.15,  “< member  record  name  clause >”  on  page  46: 

The  <  record  name>  contained  in  a  <  member  record  name  clause  >  of  a  <set  type>  shall  not  be  the  same 
as  the  <  record  name>  contained  in  the  <  owner  clause  >  of  that  <set  type>. 
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A.  Example  suppliers  and  parts  problem 

(This  annex  is  not  an  integral  part  of  the  body  of  the  standard.) 

The  following  annex  provides  an  example  2  <schema>,  <subschema>,  principal  elements  of  a  COBOL 
program,  and  <module>  for  a  "Suppliers  and  Parts"  problem. 


A.l  Example  suppliers  and  parts  <  schema  > 

SCHEMA  SUPPLIERS _ AND _ PARTS 

RECORD  S 

UNIQUE  SNO 
ITEM  SNO  CHARACTER  5 
ITEM  SNAME  CHARACTER  20 
ITEM  SSTATUS  NUMERIC  3 
ITEM  CITY  CHARACTER  15 

RECORD P 

UNIQUE  PNO 

ITEM  PNO  CHARACTER  6 

ITEM  PNAME  CHARACTER  20 

ITEM  COLOR  CHARACTER  6 

ITEM  WEIGHT  NUMERIC  3  DEFAULT  -1 

ITEM  CITY  CHARACTER  15 

RECORD  SP 

UNIQUE  SNO  PNO 
ITEM  SNO  CHARACTER  5 
ITEM  PNO  CHARACTER  6 
ITEM  QTY  NUMERIC  5 
CHECK  QTY  >=  0 


Adapted  from  chapters  24  through  26  of  C.J.  Date,  "An  Introduction  to  Database  Systems  (Third  Edition)", 
Addison-Wesley,  Menlo  Park,  California,  USA,  1981. 
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SET  S_SP 

OWNER  S 

ORDER  SORTED  DUPLICATES  PROHIBITED 
MEMBER  SP 

INSERTION  STRUCTURAL  SP.SNO  =  S.SNO 
RETENTION  FIXED 
KEY  ASCENDING  PNO 


SET  P_SP 

OWNER  P 

ORDER  SORTED  DUPLICATES  PROHIBITED 
MEMBER  SP 

INSERTION  STRUCTURAL  SP.PNO  =  P.PNO 
RETENTION  FIXED 
KEY  ASCENDING  SNO 


A.  2  Example  suppliers  and  parts  <  subschema  > 

SUBSCHEMA  SUPPLIERS  OF  SUPPLIERS_AND_PARTS 

RECORD  S 

ITEM  SSTATUS 
ITEM  CITY 

RECORD  SP 
ALL 

SET  S  SP  RENAMED  SUPPLIES 


A.3  Example  suppliers  and  parts  program 


The  following  elements  of  a  COBOL  program  set  the  Status  value  of  each  Paris  Supplier  to  the  maximum 
Status  value  for  Paris  Suppliers. 

01  DB-STATUS  PIC  X(5). 

01  S-STATUS  PIC  S9(3)  SIGN  LEADING  SEPARATE. 

01  S-CITY  PIC  X(15). 

01  M  PIC  S9(3). 

01  NOTFOUND  PIC  XXX. 

01  LISTEMPTY  PIC  XXX. 

MAINLINE. 

CALL  ’begin’  USING  DB-STATUS. 

PERFORM  CHECK-FOR-DB-ERROR. 

MOVE  ’PARIS’  TO  S-CITY. 

MOVE  ZERO  TO  M. 

MOVE  ’NO’  TO  NOTFOUND. 
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CALL  ’find-first-s’  USING  S-CITY  DB-STATUS. 

IF  DB-STATUS  =  ’00100’ 

DISPLAY  ’No  suppliers  for  Paris’ 

STOP  RUN. 

PERFORM  CHECK-FOR-DB-ERROR. 

PERFORM  UNTIL  NOTFOUND  =  ’YES’ 

CALL  ’keep-s’  USING  DB-STATUS. 

PERFORM  CHECK-FOR-DB-ERROR. 

CALL  ’get-s’  USING  S-STATUS  DB-STATUS. 
PERFORM  CHECK-FOR-DB-ERROR. 

IF  S-STATUS  GREATER  THAN  M 
MOVE  S-STATUS  TO  M. 

CALL  ’find-next-s’  USING  S-CITY  DB-STATUS. 
IF  DB-STATUS  =  ’00100’ 

MOVE  ’YES’  TO  NOTFOUND. 
PERFORM  CHECK-FOR-DB-ERROR. 
END-PERFORM 

MOVE  ’NO’  TO  LISTEMPTY. 

PERFORM  UNTIL  LISTEMPTY  =  ’YES’ 

CALL  ’find-free-modify’  USING  M  DB-STATUS. 
IF  DB-STATUS  -  ’00100’ 

MOVE  ’YES’  TO  LISTEMPTY. 
PERFORM  CHECK-FOR-DB-ERROR. 
END-PERFORM 

CALL  ’commit-finish’  USING  DB-STATUS. 

PERFORM  CHECK-FOR-DB-ERROR. 

DISPLAY  ’Processing  complete’. 

STOP  RUN. 

CHECK-FOR-DB-ERROR. 

IF  DB-STATUS  NOT  EQUAL  ’00000’  AND  ’00100’ 
DISPLAY  ’Database  error  ’  DB-STATUS 
STOP  RUN. 


A.4  Example  suppliers  and  parts  <  module  > 

MODULE 

LANGUAGE  COBOL 

SUBSCHEMA  SUPPLIERS  OF  SUPPLIERS_AND__PARTS 
SETLISTA 

PROCEDURE  begin  STATUS 

READY  S  SHARED  UPDATE 

PROCEDURE  ’find-first-s’ 

S _ CITY  CHARACTER  15 

STATUS 

FIND  FIRST  S  WHERE  CITY  =  S  CITY 
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PROCEDURE  ’find-next-s’ 

S _ CITY  CHARACTER  15 

STATUS 

FIND  NEXT  S  WHERE  CITY  =  S_CITY 

PROCEDURE  ’keep-s’  STATUS 
CONNECTS  TO  LISTA 

PROCEDURE  ’get-s’ 

S _ STATUS  NUMERIC  3 

STATUS 

GET  S  SET  S  STATUS  TO  SSTATUS 


PROCEDURE  ’find-free-modify’ 

S__STATUS  NUMERIC  3 
STATUS 

FIND  FIRST  S  IN  LISTA  FOR  UPDATE 
DISCONNECT  MEMBER  LISTA  FROM  LISTA 
MODIFY  S  SET  SSTATUS  TO  S_STATUS 

PROCEDURE  ’commit-finish’  STATUS 
COMMIT  FINISH 
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B.  Example  recursive  set  problem 

(This  annex  is  not  an  integral  part  of  the  body  of  the  standard.) 

The  following  annex  provides  an  example  <schema>,  <subschema>,  PL/I  program,  and  <module>  for  a 
"Recursive  Set"  problem. 


B.l  Example  recursive  set  < schema > 

SCHEMA  ORGANIZATION 

RECORD  EMPLOYEE 
UNIQUE  ID 

ITEM  ID  CHARACTER  5 
ITEM  NAME  CHARACTER  20 
ITEM  MANAGERID  CHARACTERS 

SET  ORGANIZATION _ STRUCTURE 

OWNER  EMPLOYEE 
ORDER  LAST 
MEMBER  EMPLOYEE 

INSERTION  STRUCTURAL  MEMBER.MANAGERID  =  OWNER.ID 
RETENTION  MANDATORY 


B.2  Example  recursive  set  <  subschema > 

SUBSCHEMA  CHART  OF  ORGANIZATION 

RECORD  EMPLOYEE  ALL 

SET  ORGANIZATION  STRUCTURE 


B.3  Example  recursive  set  program 

The  following  PL/I  program  lists  a  specific  set  occurrence  of  the  the  ORGANIZATION _ STRUCTURE  set 

type  in  top-down,  left-to-right  order. 

PRINT _ CHART :  PROC; 

DCL  begin  ENTRY  (CHAR(5)); 

DCL  find _ root _ emp  ENTRY  (CHAR(5),  CHAR(5)); 

DCL  get _ employee  ENTRY  (CHAR(20)); 

DCL  find _ next _ as _ member  ENTRY  (CHAR(5)); 

DCL  find _ member _ as _ owner  ENTRY ; 

DCL  find _ owner _ as _ member  ENTRY; 

DCL  finish  ENTRY  (CHAR(5)); 


B.  Example  recursive  set  problem 
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DCL  DB _ STATUS  CHARACTERS); 

DCL  E _ ID  CHARACTERS); 

DCL  E _ NAME  CHARACTER(20) ; 

CALL  begin  (DB _ STATUS); 

IF  DB _ STATUS  -  =  ’00000’  THEN  GOTO  DB _ ERROR; 

GET  LIST(E _ ID); 

CALL  find _ root _ emp  (E _ ID,  DB _ STATUS); 

IF  DB _ STATUS  =  ’00100’ 

THEN  DO; 

PUT  LIST( ’employee  ’  |  |  E_ID  |  |  ’  not  found’); 
RETURN; 

END; 

IF  DB _ STATUS  -  =  ’00000’  THEN  GOTO  DB _ ERROR; 

CALL  RECURSION; 

CALL  finish  (DB _ STATUS); 

IF  DB _ STATUS  =  ’00000’  THEN  GOTO  DB _ ERROR; 

PUT  LIST( ’Processing  complete’); 

RETURN; 


DB _ ERROR: 

PUT  LIST (’database  error  ’  |  |  DB _ STATUS); 

RETURN; 

RECURSION:  PROCEDURE  RECURSIVE; 

CALL  get _ employee(E  NAME); 

PUT  LIST(E _ NAME); 

CALL  find _ next _ as _ member(DB _ STATUS) ; 

DO  WHILE  DB _ STATUS  =  ’00000’ 

CALL  find _ member _ as _ owner; 

CALL  RECURSION; 

CALL  find _ owner _ as _ member; 

CALL  find _ next _ as _ member  (DB _ STATUS); 

END; 

END  RECURSION; 

END  PRINT _ CHART ; 
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B.4  Example  recursive  set  < module > 

MODULE 

LANGUAGE  PLI 

SUBSCHEMA  CHART  OF  ORGANIZATION 

PROCEDURE  begin  STATUS 

READY  EMPLOYEE  SHARED  RETRIEVE 

PROCEDURE  find _ root _ emp 

E _ ID  CHARACTER  5 

STATUS 

FIND  FIRST  EMPLOYEE  WHERE  ID  =  E_ID 

PROCEDURE  get _ employee 

E _ NAME  CHARACTER  20 

GET  EMPLOYEE  SET  E _ NAME  TO  NAME 

PROCEDURE  find _ next _ as _ member  STATUS 

FIND  NEXT  EMPLOYEE  IN  ORGANIZATION _ STRUCTURE 

AS  MEMBER  ORGANIZATION _ STRU CTURE 

PROCEDURE  find _ member _ as _ owner 

FIND  MEMBER  ORGANIZATION _ STRUCTURE 

PROCEDURE  find _ owner _ as _ member 

FIND  OWNER  ORGANIZATION _ STRUCTURE 

AS  MEMBER  ORGANIZATION _ STRU  CTURE 

PROCEDURE  finish  STATUS 
COMMIT  FINISH 


B.  Example  recursive  set  problem 
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C.  Example  bill  of  materials  problem 

(This  annex  is  not  an  integral  part  of  the  body  of  the  standard.) 


The  following  annex  provides  an  example  <schema>,  <subschema>,  FORTRAN  program,  and  <module> 
for  a  "Bill  of  Materials"  problem. 


C.l  Example  bill  of  materials  <  schema > 

SCHEMA  PARTS 

RECORD  PART 

UNIQUE  ID 

ITEM  ID  CHARACTER  5 
ITEM  NAME  CHARACTER  20 

RECORD  STRUCTURE 

UNIQUE  PARENTID  COMPONENTID 
ITEM  PARENTID  CHARACTER  5 
ITEM  COMPONENTID  CHARACTERS 
ITEM  QUANTITY  INTEGER 

SET  USES 

OWNER  PART 
ORDER  NEXT 
MEMBER  STRUCTURE 

INSERTION  STRUCTURAL 

STRUCTURE. PARENTID  =  PART. ID 
RETENTION  MANDATORY 

SET  WHERE _ USED 

OWNER  PART 
ORDER  NEXT 
MEMBER  STRUCTURE 

INSERTION  STRUCTURAL 

STRUCTURE. COMPONENTID  =  PART. ID 
RETENTION  MANDATORY 


C.  Example  bill  of  materials  problem 
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C.2  Example  bill  of  materials  < subschema > 

SUBSCHEMA  BILL _ OF _ MATERIALS  OF  PARTS 

RECORD  PART  ALL 
RECORD  STRUCTURE  ALL 
SET  USES 

SET  WHERE  USED 


C.3  Example  bill  of  materials  program 


The  following  example  FORTRAN  program  lists  all  assemblies,  subassemblies,  and  parts  necessary  to  build  the 
"axle".  It  neither  accumulates  total  item  counts  nor  lists  a  full  indentured  parts  list. 

SUBROUTINE  BOMEXP(PRTID) 

EXTERNAL  begin,  fndprt,  fndcn,  fnddg,  fndowu,  test,  finish 


CHARACTERS  PRTID,  PID,  CID,  DBSTAT 
CHARACTER*  1  DBTST 
INTEGER  QTY 

CALL  begin  (DBSTAT) 

CALL  CHKSTS  (DBSTAT) 

CALL  fndprt  (PRTID,  DBSTAT) 

IF  (DBSTAT  .EQ.  ’00100’)  THEN 
WRITE(*,10)  PRTID 
RETURN 
END  IF 

10  FORMAT(’  Part  ’,  A5,  ’  not  found’) 

CALL  CHKSTS  (DBSTAT) 

CALL  GETCMP 

20  CALL  fnddg  (PID,  CID,  QTY,  DBSTAT) 

IF  (DBSTAT  .EQ.  ’00100’)  GOTO  30 
CALL  CHKSTS  (DBSTAT) 

WRITE  (*,  25)  PID,  QTY,  CID 

25  FORMAT(’  Each  part’,  A5,  ’contains’,  13,  ’of  part’,  A5 
CALL  fndowu  (DBSTAT) 

CALL  CHKSTS  (DBSTAT) 

CALL  test  (DBTST,  DBSTAT) 

CALL  CHKSTS  (DBSTAT) 

IF  (DBTST  .EQ.  ’O’)  THEN  CALL  GETCMP 
GOTO  20 

30  CALL  finish  (DBSTAT) 

CALL  CHKSTS  (DBSTAT) 

WRITE  (*,  35) 

35  FORMAT(’  Processing  complete’) 

RETURN 
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SUBROUTINE  GETCMP 

CHARACTER* 5  DBSTAT 

50  CALL  fndcn  (DBSTAT) 

IF  (DBSTAT  .EQ.  ’00000’)  GOTO  50 
CALL  CHKSTS  (DBSTAT) 

RETURN 

END 

SUBROUTINE  CHKSTS  (DBSTAT) 
CHARACTER*5  DBSTAT 

IF  DBSTAT  .EQ.  ’00000’)  RETURN 
40  WRITE(*,  45)  DBSTAT 
45  FORMATO  Database  error  ’,  A5) 
STOP 
END 

END 


C.4  Example  bill  of  materials  <  module  > 

MODULE 

LANGUAGE  FORTRAN 

SUBSCHEMA  BILL _ OF _ MATERIALS  OF  PARTS 

SET  STRUCTURE _ LIST 

PROCEDURE  begin  STATUS 

READY  PART  SHARED  RETRIEVE 
READY  STRUCTURE  SHARED  RETRIEVE 

PROCEDURE  fndprt 

PART _ ID  CHARACTER  5 

STATUS 

FIND  FIRST  PART  WHERE  ID  =  PART _ ED 

PROCEDURE  fndcn  STATUS 

FIND  NEXT  STRUCTURE  IN  USES 
CONNECT  STRUCTURE  TO  STRUCTURE_LIST 

PROCEDURE  fnddg 

PARENT _ ID  CHARACTERS 

COMPONENT _ ID  CHARACTER  5 

C  OMPONENT _ QT Y  INTEGER 

STATUS 

FIND  FIRST  IN  STRUCTURE_LIST 
DISCONNECT  SESSION  FROM  STRUCTURE_LIST 
GET  STRUCTURE 

SET  PARENT _ ID  TO  PARENTID 

SET  COMPONENT _ ID  TO  COMPONENT® 

SET  COMPONENT _ QTY  TO  QTY 

PROCEDURE  fndowu  STATUS 

FIND  OWNER  WHERE  USED 
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PROCEDURE  test  TEST  STATUS 
TEST  SET  EMPTY  USES 

PROCEDURE  finish  STATUS 
COMMIT  FINISH 
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<dot  style  subschema  name  clause>  60,  60 
<dot  style  subschema  specification>  65,  65 
DOUBLE  24,25,28,71 
DUPLICATES  28,43,51,122 


0 

EMPTY  28, 98 
ERASE  28,  78 

<erase  statement>  78,  69,  78,  79 
<escape  identifier>  20,  6,  20,  21 
<escape  identifier  character>  20,  20,  21 
<escape  identifier  character  representation >  20, 

20,  21 

<exact  numeric  literal>  22,  22,  23,  38 
<  exact  numeric  type>  24,  24 
EXCLUSIVE  28, 89 
<exponent>  22,  22,  23 
<extents>  26,  10,  26,  27 


0 

FIND  28,  80,  123,  124,  127,  131 
<find  cursor  disposition>  80,  80,  81,  83 
<find  intent>  80,  80,  82,  83 
<find  specific  disposition>  80,  80 


Index  133 


INDEX 


< find  specific  retention >  81,80,83 

<find  specification >  80,  80,  81,  82 

<find  statement>  80,  69,  80,  119 
FINISH  28,  66,  75,  92,  124,  127,  132 
FIRST  28,  43,  44,  51,  52,  80,  83,  123,  124,  127, 
131 

FIXED  24,28,49,72,87,91,122 
FLOAT  24,  25,  28,  72 
FOR  28, 80 

FORTRAN  13,28,65,71,129,130,131 
FROM  28,77,124,131 
FULL  28, 78 


0 

GET  28,85,124,127,131 
<get  statement>  85,  69,  85 


0 

<identifier>  20,  6,  20,  28,  32,  34,  37,  41,  60,  61, 
62,  63,  67,  69 
IN  28,80,91,127,131 

< insert  cursor  disposition >  107,  76,  87,  91,  94, 

107,  108 

<insert  operation>  107,  44,  48,  76,  87,  91,  94, 
107, 108 

<insert  record>  107,  76,  87,  91,  94,  107 
<insert  set  owner>  107,  76,  87,  91,  94,  107,  108 
Cinsert  set  type>  107,  76,  87,  91,  94,  107 
INSERTION  28,  47,  68,  122,  125,  129 
<insertion  clause>  47,  15,  45,  47,  68,  76,  86,  93, 
94,  108,  119 

<  insertion  mode>  47,  47 
INTEGER  24,  25,  28,  71,  129,  130,  131 
ITEM  28,  37,  62,  121,  122,  125,  129 


0 

KEY  28,51,122 

<key  clause >  51,  15,  43,  44,  45,  51,  52,  87,  108 

<key  duplicates>  51,  43,  44,  51,  52,  53 
<key  item>  51,51 
<key  word>  28,  6,  21,  28 


0 

LANGUAGE  28,  65,  123,  127,  131 
<language  clause>  65,  12,  65,  71 
LAST  28,43,44,51,52,68,80,83,125 
<  length  >  24,10,13,24,38,71,72 

<letter>  20,  28,  29 
<letter  or  digit>  20,  20 
< literal >  22,  6,  9,  15,  19,  22,  27,  28,  38,  56 

<lower  case  letter>  20,  20 


M 


MANDATORY  28,  49,  125,  129 
<mantissa>  22,  22,  23 
MANUAL  28,  47,  68,  76,  94 
MEMBER  28,  46,  47,  48,  54,  56,  68,  81,  88,  100, 
122,  124,  125,  127,  129 

<member  check  clause>  54,  15,  45,  48,  54,  55, 
87, 108, 119 

<member  clause>  45,  15,  16,  40,  43,  44,  45,  46, 
47,  50,  51,  52,  54,  56,  68,  86,  87,  94,  119 
<member  component  identifier>  47,  47,  48,  86, 
87,  94 

<member  record  name  clause>  46,  45,  46,  68, 
119 

<member  uniqueness  clause>  50,  15,  45,  50,  87, 
108 

MODIFY  28,  86,  124 
Cmodify  statement>  86,  44,  52,  69,  86,  87 
<module>  65,  6,  12,  13,  14,  19,  29,  65,  66,  67, 
68,  70,  71,  72,  111,  112,  119,  121,  123,  125,  127, 
129,  131 

MODULE  28,  67,  123,  127,  131 
<module  name>  67,  12,  67 
<module  name  clause>  67,  65,  67 


N 


<NDL  statement>  69,  12,  14,  69,  70,  72,  101 
<  negated  subcondition  >  17,17,18 

< newline >  28,  28,  29 

NEXT  28,  43,  44,  80,  83,  108,  124,  127,  129,  131 

<nonquote  character>  22,  22,  23 

NOT  17, 28 

NULL  28, 97 

NULLIFY  28, 88 

Cnullify  cursor  statement>  88,  69,  88 
NUMERIC  28,  124 
< numeric  literal>  22,  6,  22 
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OCCURS  26, 28 

<occurs  clause>  26,  26,  27,  36,  56,  69,  70,  101, 
103 

OF  28,  56,  60,  65,  101,  122,  123,  125,  127,  130, 
131 

<of  style  component  identifier>  56,  56 
<of  style  component  view  identifier >  101,  101 

<of  style  subschema  name  clause >  60,  60 

<of  style  subschema  specification>  65,  65 
< operand >  19,  17,  18,  19,  27,  56,  85,  86,  94, 

104,  105 

<  operand  1>  96,96 

<operand  2>  96,  96 

OPTIONAL  28,  49,  68,  76,  77 
OR  17, 28 

ORDER  28,  43,  68,  122,  125,  129 
<order  clause>  43,  15,  40,  43,  44,  51,  68,  87,  108 
<order  duplicates>  43,  43,  44,  51,  53 
< order  option >  43,  43,  44 

< owner >  112,  76,  79,  82,  84,  88,  91,  94,  98,  100, 

112,  113 

OWNER  28,  42,  47,  48,  54,  56,  68,  88,  100, 

122,  125,  127,  129,  131 

<  owner  clause>  42,  40,  42,  68,  119 

<owner  component  identifier>  47,  47,  48,  86,  94 


P 


<parameter  declaration>  69,  12,  13,  69,  70,  71, 
72,  73,  103 

<parameter  identifier>  103,  19,  103,  104 
<parameter  name>  69,  69,  70,  72,  103 
PARTIAL  28, 78 
PASCAL  28,  65,  71 
PLI  28,65,71,127 

<position>  112,  44,  79,  82,  84,  88,  94,  100,  108, 
109,  110,  112,  113 
<position  member>  81,  80,  81,  84 
<precision>  24,10,24,25,38,71,72 
PRECISION  24,25,28,71 
PRIOR  28,  43,  44,  80,  83,  108 
<procedure>  69,  12,  13,  14,  15,  20,  65,  66,  69, 
70,71,72,73 

PROCEDURE  28,  69,  123,  124,  126,  127,  131, 
132 

<procedure  name>  69,  12,  69,  70 
PROHIBITED  28,  43,  44,  51,  52,  122 
PROTECTED  28,  89 


Q 


<qualifier>  56,  47,  48,  54,  56 
<quote  representation >  22,  22,  23 


0 

READY  28,  89,  123,  127,  131 
<readylist>  115,  14,  75,  76,  77,  78,  83,  86,  89, 
91,  92,  93,  111,  115 

<ready  specification>  89,  14,  76,  77,  78,  83,  86, 
89,  90,  91,  93,  115 
<ready  statement>  89,  14,  69,  89 
REAL  24,25,28,71,72 
RECONNECT  28, 91 
<reconnect  statement>  91,  44,  52,  69,  91 
RECORD  13,  28,  34,  43,  51,  61,  69,  70,  72,  80, 
81,  83,  93,  94,  121,  122,  125,  129,  130 
<record  check  clause>  39,  15,  33,  39,  87,  95,  119 
<record  cursor>  112,  14,  79,  82,  83,  85,  86,  88, 
94,  100,  102,  112,  113 

<record  name>  34,  13,  34,  42,  43,  44,  46,  47,  52, 
54,  56,  61,  119 

<record  name  clause>  34,  33,  34 

<  record  renamed  >  61,61 

<record  type>  33,  10,  11,  12,  14,  15,  31,  33,  34, 
35,  37,  38,  39,  42,  43,  44,  45,  46,  47,  48,  49,  50, 

51,  52,  54,  55,  56,  61,  62,  63,  70,  72,  76,  77,  78, 

81,  82,  83,  84,  86,  89,  91,  93,  94,  98,  99,  101, 

102,  104,  107,  109,  119 
<record  type  domain>  80,  80,  81,  82 
<record  type  key  item>  51,  43,  51,  52 
<record  type  sequence>  43,  43,  44,  51,  52 
<record  uniqueness  clause>  35,  15,  33,  35,  48, 

87,  95 

<record  view>  61,  12,  59,  61,  62,  63,  81,  93, 

101,  112,  113 

<record  view  name>  61,  12,  61,  62,  68,  70,  72, 

76,  77,  78,  80,  81,  82,  83,  85,  86,  88,  89,  90,  91, 

93,  94,  100,  101,  102,  104,  112,  113 
< regular  identifier >  20,  20,  21 

<relation>  17,  6,  17,  18 

<  relation  condition  >  17,17,18 
RELATIVE  28,  80,  83 

<remove  operation>  109,  77,  78,  86,  87,  91,  109 
<remove  record>  109,  77,  78,  86,  87,  91,  109 
<remove  set  type>  109,  77,  78,  86,  87,  91,  109 
RENAMED  28,  61,  62,  63,  122 
RETAIN  28,  80,  81,  93 
RETENTION  28,  49,  68,  122,  125,  129 
<retention  clause>  49,  16,  45,  49,  68,  76,  77,  87, 
91 
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RETRIEVE  28,80,82,83,89,127,131 
ROLLBACK  28, 92 

<rollback  statement^  92,  14,  66,  69,  70,  92 


0 

<  scale  >  24,10,24,38,71,72 

<schema>  31,  6,  11,  12,  15,  16,  19,  29,  31,  32, 
34,  41,  42,  46,  60,  61,  63,  65,  121,  125,  129 
SCHEMA  28,32,121,129 
<schema  name>  32,  11,  32,  60,  65 
< schema  name  clause >  32,31,32 

<search  orientation>  80,  80,  81,  83 
<search  specification >  80,  80,  81,  82,  83 

<separator>  28,  6,  29 
SESSION  28,88,100,131 
<session  cursor>  112,  13,  14,  72,  79,  82,  83,  85, 
88,  94,  100,112,  113 

<session  state>  111,  13,  14,  66,  73,  89,  111,  113 
SET  28,  41,  63,  68,  81,  93,  98,  99,  104,  122,  123, 
124,  125,  127,  129,  130,  131,  132 
<set  cursor>  112,  14,  44,  76,  79,  82,  83,  84,  88, 
91,  94,  98,  100,  107,  108,  109,  110,  112,  113 
<set  domain>  80,  80,  81,  82,  83 
<set  name>  41,  11,  41,  63,  78,  87,  94,  107,  109 
< set  name  clause >  41,40,41,68 

<set  renamed>  63,  63 

<set  type>  40,  11,  12,  13,  14,  15,  16,  31,  40,  41, 
42,  43,  44,  45,  46,  47,  49,  50,  51,  52,  53,  54,  55, 

56,  63,  68,  70,  76,  77,  78,  81,  82,  84,  86,  87,  91, 

93,  94,  98,  99,  100,  107,  108,  109,  113,  114,  119 
<set  view>  63,  12,  59,  63,  68,  93,  94,  112,  113 
<set  view  name>  63,  12,  63,  68,  70,  76,  77,  80, 

81,  82,  83,  84,  86,  88,  91,  93,  94,  98,  99,  100, 

107,  109,  112,  113 
<share  specification>  89,  89 
SHARED  28,  89,  123,  127,  131 
<signed  integer>  22,  22,  23,  24,  80,  81,  83 
< simple  condition>  17,17,18 
SORTED  28,  43,  122 
< sorted  order>  43,43,44,51,52 
<space>  28, 28 
<special  character>  28,  28,  29 
STATUS  13,  14,  28,  69,  70,  72,  73,  1 17,  123, 

124, 127, 131 
STORE  28, 93 
<store  retention>  93,  93,  94 
< store  statement  93,  38,  44,  52,  69,  93,  95 
STRUCTURAL  28,  47,  48,  86,  94,  119,  122,  125, 
129 

<structural  specification >  47,  47,  1 19 

<  subcondition  >  17,  17 


<subschema>  59,  12,  14,  29,  59,  60,  61,  62,  63, 
65,  68,  70,  75,  81,  92,  93,  94,  98,  112,  121,  122, 
125,  129,  130 

SUBSCHEMA  28,  60,  65,  80,  122,  123,  125, 
127,  130,  131 

<subschema  domain>  80,  80,  81,  82 
<subschema  name>  60,  12,  60,  65 
<subschema  name  clause>  60,  6,  59,  60 
<subschema  specification >  65,  6,  12,  65 

<subscripts>  27,  6,  10,  27,  35,  47,  50,  51,  56,  57, 
101,  102,  103 
SYSTEM  11,28,42,68 


0 

<temporary  set>  114,  13,  14,  75,  92,  1 14 
Ctemporary  set  specification >  68,  13,  68,  112, 

113 

<temporary  set  specifications >  68,  12,  65,  68,  70, 

111,  114,  119 

< temporary  sets >  114,  14,75,92,  111,  114 

TEST  13,  28,  69,  70,  73,  96,  97,  98,  99,  132 
<test  database  key  equal  statement>  96,  6,  69,  96 
<test  database  key  null  statement>  97,  69,  97 
<test  set  empty  statement>  98,  69,  98 
<test  set  membership  statement>  99,  69,  99 
<test  statement>  69,  69,  70 
TO  28,76,104,124,127,131 
<to  database  move>  104,  86,  93,  94,  104 
<to  database  move  clause>  104,  86,  94,  104 
<to  parameter  move>  104,  85,  104 
<to  parameter  move  clause>  104,  85,  104 
TYPE  28,43,51 


<  underscore  >  20,  20 

UNIQUE  28,  35,  50,  121,  125,  129 
<unsigned  integer>  22,  10,  22,  23,  24,  26,  27 
UPDATE  28,  76,  77,  78,  80,  83,  86,  89,  91,  93, 
123, 124 

<upper  case  letter>  20,  20 


W 


WHERE  28,80,81,123,124,127,131 
WITH  28, 78 
<word>  28, 29 
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X3. 115-1984  Unformatted  80  Megabyte  Trident  Pack  for  Use 
at  370  tpi  and  6000  bp i  (General,  Physical,  and  Magnetic  Charac¬ 
teristics) 

X3. 116-1986  Recorded  Magnetic  Tape  Cartridge,  4-Track,  Serial 
0.250  Inch  (6.30  mm)  6400  bpi  (252  bpmm).  Inverted  Modified 
Frequency  Modulation  Encoded 

X3. 117-1984  Printable/lmage  Areas  for  Text  and  Facsimile  Com¬ 
munication  Equipment 

X3. 118-1984  Financial  Services  —  Personal  Identification  Number 
-  PIN  Pad 

X3. 119-1984  Contact  Start/Stop  Storage  Disk,  1  58361  Flux  Trans¬ 
itions  per  Track,  8.268  Inch  (210  mm)  Outer  Diameter  and  3.937 
inch  (100  mm)  Inner  Diameter 
X3. 120-1984  Contact  Start/Stop  Storage  Disk 
X3. 121-1984  Two-Sided,  Unformatted,  8-Inch  (200-mm),  48-tpi, 
Double-Density,  Flexible  Disk  Cartridge  for  13  262  ftpr  Two-Headed 
Application 

X3. 122-1986  Computer  Graphics  Metafile  for  the  Storage  and 
Transfer  of  Picture  Description  Information 
X3. 124-1985  Graphical  Kernel  System  (GKS)  Functional 
Description 

X3. 124.1-1985  Graphical  Kernel  System  (GKS)  FORTRAN 
Binding 

X3. 125-1985  Two-Sided,  Double-Density,  Unformatted  5.25-inch 
(1  30-mm),  48-tpi  (1 ,9-tpmm).  Flexible  Disk  Cartridge  for  7958 
bpr  Use 

X3. 126-1986  One-  or  Two-Sided  Double-Density  Unformatted 
5.25-inch  (1  30-mm),  96  Tracks  per  Inch,  Flexible  Disk  Cartridge 
X3. 127-1987  Unrecorded  Magnetic  Tape  Cartridge  for  Information 
I  nterchange 

X3. 128-1986  Contact  Start-Stop  Storage  Disk  —  83  000  Flux 
Transitions  per  Track,  1  30-mm  (5.1 18-in)  Outer  Diameter  and 
40-mm  (1.575-in)  Inner  Diameter 

X3. 129-1986  Intelligent  Peripheral  Interface,  Physical  Level 
X3. 130-1986  Intelligent  Peripheral  Interface,  Logical  Device 
Specific  Command  Sets  for  Magnetic  Disk  Drive 


X3. 131-1986  Small  Computer  Systems  Interface 

X3. 132-1987  Intelligent  Peripheral  Interface  —  Logical  Device 

Generic  Command  Set  for  Optical  and  Magnetic  Disks 

X3. 133-1986  Database  Language —NDL 

X3. 135-1986  Database  Language  —  SQL 

X3. 136-1986  Serial  Recorded  Magnetic  Tape  Cartridge  for 

Information  Interchange,  Four  and  Nine  Track 

X3. 139-1987  Fiber  Distributed  Data  Interface  (FDDI)  Token  Ring 

Media  Access  Control  (MAC) 

X3. 140-1986  Open  Systems  Interconnection  —  Connection 
Oriented  Transport  Layer  Protocol  Specification 
X3. 141-1987  Data  Communication  Systems  and  Services  —  Mea¬ 
surement  Methods  for  User -Oriented  Performance  Evaluation 
X3. 146-1 987  Device  Level  Interface  for  Streaming  Cartridge 
and  Cassette  Tape  Drives 

X3. 147-1987  Intelligent  Peripheral  Interface  —  Logical  Device 
Generic  Command  Set  for  Magnetic  Tapes 

X3. 153-1987  Open  Systems  Interconnection  —  Basic  Connection 

Oriented  Session  Protocol  Specification 

X1 1.1-1977  Programming  Language  MUMPS 

IEEE  416-1978  Abbreviated  Test  Language  for  All  Systems 

(ATLAS) 

IEEE  716-1982  Standard  C/ATLAS  Language 

IEEE  717-1982  Standard  C/ATLAS  Syntax 

IEEE  770X3.97-1983  Programming  Language  PASCAL 

IEEE  771-1980  Guide  to  the  Use  of  ATLAS 

ISO  8211-1986  Specifications  for  a  Data  Descriptive  File  for 

Information  Interchange 

MIL-STD-1815A-1983  Reference  Manual  for  the  Ada  Programming 
Language 

NBS-ICST  1-1986  Fingerprint  Identification  —  Data  Format  for 
Information  Interchange 


X3/TRI-82  Dictionary  for  Information  Processing  Systems 
(Technical  Report) 


American  National  Standards  for  Information  Processing 


X3. 1-1976  Synchronous  Signaling  Rates  for  Data  Transmission 
X3. 2-1970  Print  Specifications  for  Magnetic  Ink  Character 
Recognition 

X3.4-1986  Coded  Character  Sets  —  7-Bit  ASCII 
X3.5-1970,.FIowchart  Symbols  and  Their  Usage 
X3.6-1965  Perforated  Tape  Code 
X3.9-1978  Programming  Language  FORTRAN 
X3. 11-1969  General  Purpose  Paper  Cards 
X3.14-1983  Recorded  Magnetic  Tape  (200  CPI,  NRZI) 

X3.15-1976  Bit  Sequencing  of  the  American  National  Standard 
Code  for  Information  Interchange  in  Serial-by-Bit  Data  Transmission 
X3. 16-1976  Character  Structure  and  Character  Parity  Sense  for 
Serial-by-Bit  Data  Communication  in  the  American  National  Stan¬ 
dard  Code  for  Information  Interchange 
X3.17-1981  Character  Set  for  Optical  Character  Recognition 
(OCR-A) 

X3. 18-1974  One-Inch  Perforated  Paper  Tape 
X3. 19-1974  Eleven-Sixteenths-Inch  Perforated  Paper  Tape 
X3.20-1967  Take-Up  Reels  for  One-Inch  Perforated  Tape 
X3.21-1967  Rectangular  Holes  in  Twelve-Row  Punched  Cards 
X3. 22-1983  Recorded  Magnetic  Tape  (800  CPI,  NRZI) 

X3. 23-1985  Programming  Language  COBOL 

X3. 25-1976  Character  Structure  and  Character  Parity  Sense  for 

Parallel-by-Bit  Data  Communication  in  the  American  National 

Standard  Code  for  Information  Interchange 

X3. 26-1980  Hollerith  Punched  Card  Code 

X3.27-1978  Magnetic  Tape  Labels  and  File  Structure 

X3. 28-1976  Procedures  for  the  Use  of  the  Communication  Control 

Characters  of  American  National  Standard  Code  for  Information 

Interchange  in  Specified  Data  Communication  Links 

X3.29-1971  Specifications  for  Properties  of  Unpunched  Oiled 

Paper  Perforator  Tape 

X3. 30-1986  Representation  for  Calendar  Date  and  Ordinal  Date 
X3.31-1973  Structure  for  the  Identification  of  the  Counties  of  the 
United  States 

X3. 32-1973  Graphic  Representation  of  the  Control  Characters  of 
American  National  Standard  Code  for  Information  Interchange 
X3. 34-1972  Interchange  Rolls  of  Perforated  Tape 
X3.37-1980  Programming  Language  APT 
X3.38-1972  Identification  of  States  of  the  United  States 
(Including  the  District  of  Columbia) 

X3. 39-1986  Recorded  Magnetic  Tape  (1600  CPI,  PE) 

X3.40-1983  Unrecorded  Magnetic  Tape  (9-Track  800  CPI,  NRZI; 
1600  CPI,  PE;  and  6250  CPI,  GCR) 

X3.41-1974  Code  Extension  Techniques  for  Use  with  the  7-Bit 
Coded  Character  Set  of  American  National  Standard  Code  for  Infor¬ 
mation  Interchange 

X3.42-1975  Representation  of  Numeric  Values  in  Character  Strings 
X3.43-1986  Representations  of  Local  Time  of  Day 
X3.44-1974  Determination  of  the  Performance  of  Data  Communi¬ 
cation  Systems 

X3.45-1982  Character  Set  for  Handprinting 

X3. 46-1974  Unrecorded  Magnetic  Six-Disk  Pack  (General,  Physical, 
and  Magnetic  Characteristics) 

X3.47-1977  Structure  for  the  Identification  of  Named  Populated 
Places  and  Related  Entities  of  the  States  of  the  United  States  for 
Information  Interchange 

X3.48-1986  Magnetic  Tape  Cassettes  (3.81 -mm  [0.150-Inch) 

Tape  at  32  bpmm  [800  bpi] ,  PE) 

X3.49-1975  Character  Set  for  Optical  Character  Recognition  (OCR-B) 
X3. 50-1986  Representations  for  U.S.  Customary,  SI,  and  Other 
Units  to  Be  Used  in  Systems  with  Limited  Character  Sets 
X3. 51-1986  Representations  of  Universal  Time,  Local  Time  Differ¬ 
entials,  and  United  States  Time  Zone  References 
X3.52-1976  Unrecorded  Single-Disk  Cartridge  (Front  Loading, 

2200  BPI)  (General,  Physical,  and  Magnetic  Requirements) 

X3. 53-1976  Programming  Language  PL/I 

X3. 54-1986  Recorded  Magnetic  Tape  (6250  CPI,  Group  Coded 

Recording) 

X3.55-1982  Unrecorded  Magnetic  Tape  Cartridge,  0.250  Inch 

(6.30  mm),  1600  bpi  (63  bpmm).  Phase  encoded 

X3. 56-1986  Recorded  Magnetic  Tape  Cartridge,  4  Track,  0.250 

Inch  (6.30  mm),  1600  bpi  (63  bpmm).  Phase  Encoded 

X3. 57-1977  Structure  for  Formatting  Message  Headings  Using  the 

American  National  Standard  Code  for  Information  Interchange  for 

Data  Communication  Systems  Control 


X3. 58-1977  Unrecorded  Eleven-Disk  Pack  (General,  Physical,  and 
Magnetic  Requirements) 

X3.60-1978  Programming  Language  Minimal  BASIC 
X3.61-1986  Representation  of  Geographic  Point  Locations 
X3.62-1987  Paper  Used  in  Optical  Character  Recognition  (OCR) 
Systems 

X3.63-1981  Unrecorded  Twelve-Disk  Pack  (100  Megabytes)  (Gen¬ 
eral,  Physical,  and  Magnetic  Requirements) 

X3.64-1979  Additional  Controls  for  Use  with  American  National 
Standard  Code  for  Information  Interchange 
X3.66-1979  Advanced  Data  Communication  Control  Procedures 
(ADCCP) 

X3. 72-1981  Parallel  Recorded  Magnetic  Tape  Cartridge,  4  Track, 
0.250  Inch  (6.30  mm),  1600  bpi  (63  bpmm),  Phase  Encoded 
X3.73-1980  Single-Sided  Unformatted  Flexible  Disk  Cartridge 
(for  6631 -BPR  Use) 

X3. 74-1981  Programming  Language  PL/I,  General-Purpose  Subset 
X3. 76-1981  Unformatted  Single-Disk  Cartridge  (Top  Loading, 

200  tpi  4400  bpi)  (General,  Physical,  and  Magnetic  Requirements) 
X3.77-1980  Representation  of  Pocket  Select  Characters 
X3.78-1981  Representation  of  Vertical  Carriage  Positioning  Char¬ 
acters  in  Information  Interchange 

X3.79-1981  Determination  of  Performance  of  Data  Communica¬ 
tions  Systems  That  Use  Bit-Oriented  Communication  Procedures 
X3.80-1981  Interfaces  between  Flexible  Disk  Cartridge  Drives 
and  Their  Host  Controllers 

X3.82-1980  One-Sided  Single-Density  Unformatted  5.25-Inch 
Flexible  Disk  Cartridge  (for  3979-BPR  Use) 

X3. 83-1980  ANSI  Sponsorship  Procedures  for  ISO  Registration 
According  to  ISO  2375 

X3.84-1981  Unformatted  Twelve-Disk  Pack  (200  MegabytesHGen- 
eral,  Physical,  and  Magnetic  Requirements 
X3.85-1981  1/2-Inch  Magnetic  Tape  Interchange  Using  a  Self 
Loading  Cartridge 

X3.86-1980  Optical  Character  Recognition  (OCR)  Inks 
X3.88-1981  Computer  Program  Abstracts 
X3. 89-1981  Unrecorded  Single-Disk,  Double-Density  Cartridge 
(Front  Loading,  2200  bpi,  200  tpi)  (General,  Physical,  and  Mag¬ 
netic  Requirements) 

X3.91M-1987  Storage  Module  Interfaces 

X3. 92-1981  Data  Encryption  Algorithm 

X3.93M-1981  OCR  Character  Positioning 

X3.94-1985  Programming  Language  PANCM 

X3.95-1982  Microprocessors  —  Hexadecimal  Input/Output,  Using 

5-Bit  and  7-Bit  Teleprinters 

X3. 96-1983  Continuous  Business  Forms  (Single-Part) 

X3.98-1983  Text  Information  Interchange  in  Page  Image  Format 
(PIF) 

X3.99-1983  Print  Quality  Guideline  for  Optical  Character  Recogni¬ 
tion  (OCR) 

X3. 100-1983  Interface  Between  Data  Terminal  Equipment  and 
Data  Circuit-Terminating  Equipment  for  Packet  Mode  Operation 
with  Packet  Switched  Data  Communications  Network 
X3. 101-1984  Interfaces  Between  Rigid  Disk  Drivels)  and  Host(s) 

X3. 102-1983  Data  Communication  Systems  and  Services  —  User- 
Oriented  Performance  Parameters 

X3. 103-1983  Unrecorded  Magnetic  Tape  Minicassette  for  Informa¬ 
tion  Interchange,  Coplanar  3.81  mm  (0.150  in) 

X3.104-1983  Recorded  Magnetic  Tape  Minicassette  for  Informa¬ 
tion  Interchange,  Coplanar  3.81  mm  (0.150  in).  Phase  Encoded 
X3.105-1983  Data  Link  Encryption 

X3.106-1983  Modes  of  Operation  for  the  Data  Encryption  Algorithm 
X3. 110-1983  Videotex/Teletext  Presentation  Level  Protocol  Syntax 
X3.1 11-1986  Optical  Character  Recognition  (OCR)  Matrix  Charac¬ 
ter  Sets  for  OCR-M 

X3.112-1984  14-in  (356-mm)  Diameter  Low-Surface-Friction 
Magnetic  Storage  Disk 

X3. 113-1987  Programming  Language  FULL  BASIC 

X3. 114-1984  Alphanumeric  Machines;  Coded  Character  Sets  for 

Keyboard  Arrangements  in  ANSI  X4. 23-1982  and  X4. 22-1983 

( Continued  on  reverse ) 
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